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ABSTRACT 


This  CAPSTONE  Report  documents  the  Systems  Engineering  (SE)  efforts  of 
“Team  Marine,”  from  JAN  2009  to  SEP  2009,  in  developing  a  recommendation  to  the  US 
Marine  Corps  Systems  Command  (MCSC),  on  the  best  course  of  action  to  ‘Enhance  the 
USMC  Expeditionary  Rifle  Squad  Communications  System.’ 

The  squad  leader  is  the  cornerstone  for  USMC  tactical  operations.  Clear,  concise, 
accurate  and  reliable  communications  to  and  from  the  squad  leader  is  the  key  to  squad 
operations,  performance  and  tactical  effectiveness.  Today’s  fielded  communications 
system  for  the  squad  leader  requires  the  use  of  two  separate  radios,  each  with  different 
encryption  algorithms,  different  user  interfaces,  and  different  data  processing  capabilities. 
This  primitive  design  has  thrust  the  squad  leader  into  a  complex  Human  Factors 
environment  with  disparate  components  that  have  not  been  well  engineered  or  integrated. 

Team  Marine  applied  and  tailored  the  systems  engineering  (SE)  process  based  on 
NPS  course  work  and  professional  experience.  This  SE  process  enabled  the  team  to 
completely  understand  and  model  the  current  system  in  terms  of  architecture,  capabilities 
and  functions.  The  process  led  the  team  and  stakeholders  to  conclude  that  an  evolutionary 
approach  of  system  integration  was  preferred  over  the  traditional  Manufacturer  A  vs. 
Manufacturer  B  run  off. 

The  team’s  recommendation  is  to  pursue  an  integrated  communications  system, 
based  on  existing  and  emerging  components,  as  the  best  course  of  action.  The  first 
incremental  step  of  the  recommendation  is  to  upgrade  the  existing  elements  by  adding  an 
automated  communications  processor  with  enhanced  human  to  system  interfaces. 
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EXECUTIVE  SUMMARY 


The  United  States  Marine  Corps  (USMC)  squad  is  the  cornerstone  for  tactical 
operations.  Clear,  concise,  accurate  and  reliable  communications  to  and  from  the  squad 
leader  are  the  key  to  squad  operations,  performance,  and  tactical  effectiveness.  The 
squad  leader  is  required  to  receive  and  accept  tasking  by  higher  authorities,  request 
additional  support  as  needed  by  available  command  elements,  and  must  continually 
update  and  report  unit  status  to  other  squad  leaders  and  platoon  commanders.  All  of 
these  actions  occur  while  simultaneously;  communicating  orders  and  intent,  coordinating 
the  movement  of,  and  directing  the  actions  of  each  individual  squad  member  during  all 
phases  of  operations. 

Today’s  fielded  communications  system  for  the  squad  leader  requires  two 
separate  radios,  each  with  different  encryption  algorithms,  different  user  interfaces,  and 
different  data  processing  capabilities.  The  squad  members  have  one  type  of  radio  for 
inter-squad  communications,  while  the  squad  leader  has  to  carry  an  additional  radio  to 
communicate  with  higher  echelons.  This  primitive  design  has  thrust  the  squad  leader  into 
a  complex  Human  Factors  environment  with  disparate  components  that  have  not  been 
well  engineered  or  integrated.  The  squad  leader  must  now  configure,  manage  and 
communicate  on  two  separate  radios,  while  still  being  required  to  deploy  and  operate 
weapons. 

This  poorly  integrated  system  has  created  an  extensive,  confusing,  and  costly 
logistics  trail  for  the  USMC  to  manage,  since  each  radio  requires  unique  power  and 
peripheral  devices  as  well  as  unique  training.  The  lack  of  an  integrated  communications 
system  affects  day  to  day  operations.  Since  each  radio  component  is  a  stand-alone 
element,  the  squad  leader’s  physical  and  mental  workload  is  increased  by  processing  data 
between  two  radios  and  up  to  10  different  radio  circuits.  Each  USMC  squad  deploys 
unique  configurations  which  are  unable  to  communicate  with  nearby  Joint  and  Coalition 
squads. 
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The  Naval  Post-graduate  School  (NPS)  Cohort  -  Systems  Engineering  (SE)  team, 
known  as  Team  Marine,  accepted  the  challenge  of  'Enhancing  the  USMC  Rifle  Squad 
Communications  System. '  The  challenge  originated  from  discussions  with  senior 
leadership  from  Marine  Corps  Systems  Command,  and  the  Program  Manager  for  the 
Marine  Expeditionary  Rifle  Squad  program  office.  To  meet  the  challenge,  the  team 
applied  the  NPS  SE  practices  and  analysis  methods. 

The  System  Engineering  Design  Process  (SEDP)  was  used  to  understand  the 
needs  of  the  customer.  Non-material  alternatives  were  not  considered  to  be  viable  to 
solve  the  capability  problem.  Four  (4)  possible  material  alternative  solutions  were 
developed  to  meet  the  customer  requirements.  These  four  alternative  solutions  were 
derived  from  the  Functional  Architecture,  Physical  Architecture,  and  Operational 
Architecture. 

Through  feasibility  screening,  modeling  and  simulation,  decision  scoring,  risk 
analysis  and  cost  analysis  the  team  determined  that  an  evolutionary  development  effort 
would  be  the  best  course  of  action  for  MCSC  to  undertake. 

The  team  recommends  the  following  course  of  action  (COA): 

1)  In  the  near-term,  pursue  the  Advanced  Alternative.  This  alternative  provides 
the  squad  leader  with  a  fully  integrated  system  comprised  of  wearable  and  hand-held  sub¬ 
systems.  The  input  devices  are  internal  microphones  for  voice  and  touch  screens  for  data 
input.  The  IISR  (AN/PRC- 15  3)  provides  a  short  transmission  range  of  less  than  3 
kilometers  with  degraded  capability  and  the  AN/PRC- 152  provides  long  transmission 
range  that  extends  to  10  kilometers.  This  alternative  is  the  best,  “bang  for  the  buck” 
integrated  solution.  As  systems  mature  and  technologies  become  available  MCSC  should 
be  able  to  evolve  the  system  into  the  Future  Alternative. 

2)  PM  MERS  continue  acquisition  and  development  of  the  Advanced 
Alternative.  Include  the  results  of  this  team’s  effort  as  the  foundation  for  future  analysis, 
acquisition,  and  development. 

3)  Migrate  to  the  Future  Alternative  when  feasible. 
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I  INTRODUCTION 


A  OBJECTIVE 

The  project’s  Systems  Engineering  (SE)  team  targeted  a  single  integrated, 
interoperable,  communications  system  capable  of  providing  transmission  relay,  voice  and 
data  networking,  and  communications  processing  that  can  accommodate  multiple  levels 
of  encryption  and  security  among  Marine,  Joint  and  Coalition  squads.  The  team’s  focus 
and  goal  is  to  ‘Enhance  the  USMC  Expeditionary  Rifle  Squad  Communications  System.’ 

B  BACKGROUND 

1.  The  United  States  Marine  Corps 

The  United  States  Marine  Corps  (USMC)  uses  a  multi-tiered  and  multi-faceted 
command  element  structure  known  as  the  Marine  Air-Ground  Task  Force  (MAGTF). 
The  MAGTF  is  the  premier  expeditionary  force  capable  of  responding  to  conflict  from 
the  ground,  air  and  sea.  The  MAGTF  Expeditionary  Force  (MEF)  is  divided  into  a  triad 
of  functional  command  elements  under  the  ultimate  control  of  the  MEF  Commander. 
The  USMC  Operational  View  -  1  (OV-1),  (Figure  1  below),  depicts  the  three  command 
elements  which  are  the  Ground  Command  Element  (GCE),  the  Aviation  Command 
Element  (ACE),  and  the  Logistics  Command  Element  (LCE).  Each  of  these  functional 
areas  is  divided  by  echelon.  (MAGTF  C2  ICD,  2008) 


Figure  1:  MAGTF  Operational  View  1  (OV-1)  (from  MAGTF  C2  ICD  28FEB2008) 

The  MEF  command  element  is  at  Echelon  1,  (on  the  far  left),  and  is  depicted  as  a 
CAPSET  1  Combat  Operations  Center  (COC).  This  tiered  approach  continues  across  the 
image  to  the  right,  down  to  the  CAPSET  V  components,  which  includes  the  USMC 
companies,  platoons,  squads  and  teams. 

The  MAGTF  structure  allows  the  Marines  to  maximize  their  tactical  advantage 
via  a  closely  integrated  air-ground  and  logistics  team.  A  MAGTF  can  operate  as  an 
independent  unit,  part  of  a  joint  or  combined  task  force,  as  a  separate  service  component 
or  as  a  uni-service  force  and  can  deploy  by  sealift,  airlift  or  both.  The  MAGTF  gives  the 
Marine  Corps  a  unique  flexibility  to  respond  rapidly  to  any  contingency,  anywhere  in  the 
world. 


2.  The  Squad 

The  tactical  operating  concept  for  MERS  was  developed  and  defined  through  a 
series  of  operational  scenarios  which  examined  current  and  future  employment  concepts 
for  infantry  squads.  This  analysis  assisted  in  identifying  critical  capability  gaps 
associated  with  the  status  capabilities  provided.  The  gaps  are  associated  with  the  lack  of 
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a  networking  capability  able  to  convey  Command  and  Control  (C2)  and  Situational 
Awareness  (SA)  from  higher  to  lower  echelons  of  command.  It  was  determined  that  this 
gap  was  critical  to  this  effort  and  that  the  emerging  networking  solutions  have  to  avoid 
becoming  complex  while  still  addressing  the  critical  issues  impacting  the  operations  of 
the  squad. 

''The  Marine  Expeditionary  Rifle  Squad  has  been  the  basic  building  block  for  all 
Marine  Corps  operations  and  concepts  since  the  birth  of  the  Corps.  The  squad’s 
organization  and  weapons  have  changed,  but  the  squad  continues  to  be  the  tip  of  the 
spear  with  the  mission  to  locate,  close  with  and  destroy  the  enemy.  ”  (MERS  CONOPS, 
2009) 


Squad 

Leader 


/l\ 


/?\ 


Team  Leader 


Fire  Team 


Figure  2:  USMC  Squad  context 

The  basic  mission  of  the  MERS  is  to  locate,  close  with,  and  destroy  the  enemy  by 
fire  and  maneuver,  or  repel  the  enemy’s  assault  by  fire  and  close  combat  (MERS 
CONOPS,  2009).  This  basic  mission  never  changes.  However,  the  ability  to  execute  the 
mission  has  grown  increasingly  complex,  due  to  the  introduction  of  more  and  more 
sophisticated  technologies  in  a  myriad  of  different  operational  environments. 

MERS  Tactical  Operational  Concept  walked  through  the  gamut  of  operational 
scenarios  faced  by  the  squad  in  order  to  examine  current  and  future  employment  concepts 
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for  the  infantry  squad  and  to  identify  any  capability  gaps.  The  analysis  identified 
Command  and  Control  (C2),  Situational  Awareness  (SA),  system  networking  and  its 
ability  to  become  increasingly  complex  and  organic  as  critical  issues  impacting  the 
operations  of  the  squad. 

‘"Without  the  proper  communications  equipment,  the  squad  will  not  have  the 
capability  to  seamlessly  communicate  with  joint/combined  forces.  Situational  awareness 
will  be  lost  and  combined  force  effectiveness  will  be  diminished.  The  potential  for 
fratricide  also  increases.  ”  (MERS  CONORS,  2009) 

3.  Squad  Communications 

The  expansion  of  information  systems  technology  has  fed  the  desire  for  greater 
communications  and  networking  capability  for  the  “last  tactical  mile”  on  the  battlefield. 
This  expansion  has  lead  to  the  requirement  for  the  ability  of  a  Marine  Squad  to  send  and 
receive  voice  and  data  to  higher,  adjacent  and  subordinate  personnel  on  the  battlefield. 
Per  the  Joint  Requirements  Oversight  Counsel  Memorandum  (JROCM  071-08),  senior 
military  leadership  has  determined  that  the  data  at  the  squad  and  below  is  mission 
dependent  and  may  be  either  classified  or  unclassified.  The  JROC  set  forth  the  governing 
policy  requiring  forces  operating  in  the  battle  space  to  employ  capabilities  that  protect 
Position,  Location  Information  (PLI).  This  can  be  accomplished  via  two  levels  of 
classification  and  encryption.  Two-way,  aggregate  PLI  data  at  the  CONFIDENTIAL  or 
higher  level  requires  NS  A  approved  Type  I  encryption  methods.  One-way,  non¬ 
aggregate  PLI  data  below  SECRET  must  be  protected  at  least  as  Controlled  Unclassified 
Information  (CUI),  using  NSA  approved  Type  2  encryption  methods. 

In  practice,  the  Marine  Corps  has  determined  that  both  voice  and  data 
connectivity  from  the  squad  leader  to  higher  echelons  will  be  encrypted  as  Type  I  data. 
Additionally,  the  connectivity  within  the  squad  (squad  leader  to  squad  members)  is 
considered  CUI  and  must  be  encrypted  as  Type  2  data. 

According  to  National  Information  Assurance  (2006),  a  Type  I  device  is  an 
cryptographic  equipment,  assembly  or  component  classified  by  National  Security  Agency 
(NSA)  for  encrypting  and  decrypting  classified  and  sensitivity  national  security 

information  when  appropriately  keyed.  It  is  used  to  protect  systems  requiring  the  most 
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stringent  protection  mechanisms.  A  Type  II  devise  is  a  cryptographic  piece  of 
equipment,  assembly  or  component  classified  by  NS  A  for  encrypting  or  decrypting 
sensitive  national  security  information  when  appropriately  keyed.  Type  II  classification 
is  used  to  protect  systems  requiring  protecting  mechanisms  exceeding  best  commercial 
practices  including  systems  used  for  protecting  unclassified  national  security  information. 

Both  Type  I  &  II  encryption  is  developed  using  NS  A  business  processes  and 
contains  NSA  approved  algorithms. 

This  decision  and  doctrinal  approach  introduces  complex  requirements  that  the 
currently  fielded  communications  system  cannot  easily  accommodate. 


PLT 

LDR 


PRC-152 

NSA  Approved 
Type  1  Encryption 
Classified  SECRET 
US  only 


SQD 

MBRs 


Figure  3:  Current  Squad  level  communication  solution 

The  Marine  Corps’  currently  fielded  system  was  not  engineered  nor  designed  to 
address  all  of  the  JROCM  memorandum  requirements.  Figure  3  above,  identifies  the  two 
disparate  transmission  and  encryption  devices.  The  dashed  -  red  arrows,  on  the  left  side 
of  the  diagram  represent  the  two-way,  classified.  Type  1  encrypted  data,  which  is  passed 
among  squad  leaders  and  up  to  higher  echelon  authorities  (i.e.  platoon  leaders).  The  solid 
-  black  arrows  on  the  right  side  of  the  diagram  represent  the  one  way,  Type  2,  CUI  data, 
which  is  shared  among  squad  members  and  can  be  passed  onto  joint  or  coalition  forces. 
This  simple  ad-hoc  design  lacks  technical  maturity  and  ignores  many  human  factors.  The 
configuration  deploys  two  radios  at  the  squad  leader  level;  one  is  an  AN/PRC-152  (Type 
1  Encryption)  for  voice  only  communications  between  the  squad  leaders  and  platoon 
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commander.  The  other  radio  is  an  Interim  Intra-Squad  Radio  (IlSR  (AN/PRC- 153)) 
(Type  2  Encryption)  for  voice  only  communications  between  the  squad  leader  and  squad 
members. 

The  squad  leader  now  has  to  carry,  configure  and  operate  two  physical  devices 
with  incongruent  designs  and  is  still  expected  to  carry  out  his  combat  mission,  which 
includes  engaging  enemy  forces. 

C  SCOPE,  BOUNDS,  AND  ASSUMPTIONS 

After  defining  the  objective,  the  SE  team  developed  the  context  diagram  below  in 
Figure  4.  The  diagram  depicts  the  context  of  the  system  and  intended  system  boundaries 
of  this  effort. 


Level  of  Security 

Type  1 

Type  2 

Type  1  or  2 
(Situation  dependent) 


Transmission  Type 
Voice  -  User  initiated 

Data  -  C2/SA  Device  initiated  or  automated 


Data  (one-way) 


Squad  Member 
Communications 
Device(s) 


System  Boundary 


Figure  4:  Communications  System  Context  Diagram 

Figure  4  also  shows  the  information  exchange  relationships  between  the  squad 
leader,  the  squad  members,  other  squad  leaders  (both  Joint  and  Coalition),  and  higher 


-6- 


command  authorities.  Physically,  the  system  will  be  bounded  primarily  by  the 
capabilities,  configurations,  and  interfaces  of  the  communications  system  for  the  Marine 
Rifle  Squad  Leader.  The  SE  team  further  bounded  the  problem  to  concentrate  on  the 
communication  system’s  processing  capability  and  the  corresponding  human  factors 
affecting  the  squad  leader. 

The  critical  assumptions  and  constraints  for  the  project  were  determined  and 
taken  into  consideration.  These  items  aided  the  team  in  establishing  the  boundaries  and 
scope  of  the  problem  description  as  the  team  labored  toward  an  understanding  of  the 
effective  need.  The  following  assumptions  were  defined  and  used  during  the  early  phases 
of  the  effort: 

■  No  overarching  requirement  documents  exist  for  a  squad  level 
communications  system  in  the  USMC.  Doctrine  continues  to  mature  and 
adapt  to  emerging  technologies  and  capabilities.  The  Commandant  of  the 
Marine  Corps  published  a  document  (A  Concept  for  Enhanced  Company 
Operations,  28  Aug  2008,  Department  of  the  Navy,  Headquarters  U.S.  Marine 
Corps)  to  outline  his  plan  for  Enhanced  Company  Operations  (ECO).  As 
defined  by  the  Commandant’s  concept  paper,  squad  communications  systems 
are  a  subset  of  ECO.  As  stated,  “Tactical”  units  must  gravitate  from  push-to- 
talk  radio  systems  to  mobile  ad-hoc  mesh  networking.”  Marine  Corps 
Combat  Development  Command  (MCCDC)  is  the  command  assigned  the  task 
of  rewriting  and  amplifying  doctrine.  MCCDC  is  currently  taking  several 
concept  papers  (like  the  ECO)  and  codifying  these  concepts  into  applicable 
doctrine.  While  this  doctrine  changes  and  adapts  so  do  the  technologies  to 
realize  the  conceptual  constructs  and  the  informing  doctrine. 

■  No  documented  requirement  exists  for  an  integrated  system  capability.  The 
Programs  of  Record  (PORs)  that  acquire  and  provide  communication  systems 
to  the  tactical  users  are  not  organized.  These  same  PORs  are  also  not 
mandated  to  coordinate  their  systems  acquisition  with  other  systems,  either 
currently  fielded  or  planned  to  be  fielded.  Without  an  integrated  concept  for 

the  squad  level  communication  system,  the  Rifle  Squad  will  receive  laptops 
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and  /or  Personal  Digital  Assistants  (PDAs)  from  one  POR,  radios,  Global 
Positioning  System  (GPS)  units,  and  alternative  power  sources  all  from  their 
own  respective  POR.  It  is  important  to  note  that  an  integrated  capability  (as 
defined  by  the  analysis)  is  required  in  order  for  a  successful  solution  to  be 
implemented. 

■  The  Joint  Tactical  Radio  System  (JTRS)  is  the  DoD  mandated  provider  of 
future  tactical  radios  and  associated  waveforms.  The  JTRS  Joint  Program 
Office  (JPO)  is  currently  developing  a  family  of  radios  that  are  software 
programmable  to  support  service  elements,  joint  and  other  agencies  at  the 
tactical  edge.  The  available  JTRS  products  today  are  considered  a  viable 
material  solution  for  Marine  squad  leaders.  The  examination  of  the 
alternatives  to  support  a  non-material  or  material  approach  is  vetted  via  this 
Systems  Engineering  Design  Process  (SEDP)  during  our  analysis. 

■  The  Blue  Force  Track  (BFT)  policy,  approved  by  the  JROC,  requires  joint 
communication  standards.  This  policy  defines  the  capabilities  to  establish  and 
maintain  connectivity  for  Command  and  Control  and  Situational  Awareness 
nodes.  It  also  mandates  adherence  to  a  common,  friendly  force,  plain 
language  addressing  scheme  between  friendly  forces  operating  in  theater.  The 
BFT  architecture  relies  on  a  mixture  of  US  government  and  commercially- 
leased  satellites  and  ground  control  stations. 

Other  constraints  listed  below  were  used  as  entry  criteria  for  the  final  system 
solution  to  be  considered.  MERS  documentation,  and  input  by  Key  Stakeholders  led  to 
these  constraints  being  applied.  Any  potential  alternative  system  had  to  meet  the 
following  conditions: 

■  Operate  in  Military  Spectrum  Bands  (per  FCC  guidance) 

■  National  Security  Agency  (NSA)  certified  or  certifiable 

■  Joint  Integrated  Test  Center  (JITC)  certified  or  certifiable 

■  JTRS  Service  Component  Architecture  (SCA)  2.2  compliant 

■  Requires  no  Satellite  Communication  (SATCOM)  equipment  at  the  squad 
level 
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■  Power  system  must  support  Mission  Duration  times  no  less  than  8  hours 

■  Total  system  weight  must  be  lighter  than  the  currently  fielded  system 
configuration 

■  Operate  independent  of  commercial  telecommunications  infrastructure 

■  Total  Research,  Development,  Test  and  Evaluation  (RDT&E)  costs  must  be 
less  than  current  PM  MERS  program  funds 

■  Initial  Operational  Capability  (IOC)  in  accordance  with  PM  MERS 
acquisition  documentation 

■  Full  Operational  Capability  (FOC)  in  accordance  with  PM  MERS  acquisition 
documentation 

■  Backwards  compatible  with  existing  systems  until  FOC 

D  SYSTEMS  ENGINEERING  METHODOLOGY  AND  APPROACH 

The  Systems  Engineering  Methodology  for  the  Squad  Communication  System 
was  a  tailored  process  adopted  from  original  ideas  and  various  existing  systems 
engineering  models.  Models,  concepts  and  methodologies  include  the  Traditional 
Structured  Analysis  Model  (Grady,  2009);  concepts  for  functional,  physical,  and 
operational  architecture  development  from  D.M.  Buede  (Buede,  2000);  and 
environmental  classification  definitions  by  Grady  (2009).  When  these  concepts  were 
combined,  a  roadmap  from  a  user  need  to  a  recommended  alternative  was  developed  to 
focus  the  team’s  analysis.  This  roadmap  provided  the  framework  and  direction  of  the 
effort,  from  need,  concept  development,  alternative  analysis  and  finally  a  recommended 
solution  for  the  Rifle  Squad  Communication  System. 


-9- 


Architecture  Decomposition 
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Figure  5:  Detailed  Systems  Engineering  Process 
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The  methodology  begins  with  understanding  the  user  requirements©.  This 
includes  the  development  of  a  preliminary  problem  statement  that  assesses  what  the  user 
perceives  as  the  need  to  perform  operational  tasks,  the  conditions  in  which  they  perform 
them,  gaps  in  the  current  system,  and  inferences  about  the  future  state.  These  inputs  help 
formulate  needs  and  constraints  of  the  system,  the  operational  context  in  which  it  must 
perform,  and  the  preliminary  assessment  of  system  boundaries.  With  this  information,  an 
intensive  architecture  decomposition  effort  can  further  define  these  contexts.  The 
architecture  development©  involves  the  operational,  functional,  and  physical 
decomposition  to  further  develop  the  context  of  the  system  and  create  the  basis  of 
performance  requirements  while  being  bounded  by  the  Operational  Concept.  The  end 
result  of  this  decomposition  is  a  well  defined  functionality  that  the  system  must  fulfill 
within  the  larger  context  of  the  Marine  Corps  and  a  work  breakdown  structure®. 

In  parallel  to  the  sub-system  definition,  a  complete  analysis  of  the  intended 

environments®  and  specialty  engineering  aspects®  of  the  system  will  give  sufficient 
depth  to  the  requirements  development.  The  breadth  of  environments  include  internal 
environments  the  system  itself  creates,  external  environments  that  the  system  operates  in, 
and  interfacing  systems  beyond  the  scope  of  the  system  that  is  being  defined.  Specialty 
engineering  aspects  are  captured  to  envelop  the  higher  system  level  requirements  that  are 
not  captured  within  the  decomposed  functions  For  example,  system  reliability, 
maintainability  and  survivability  are  defined  at  the  highest  system  level  and  then  flowed 
down  to  the  sub-systems  in  future  iterations.  These  specialty  engineering  aspects  also 
bound  the  system  tradespace  to  work  within  the  established  USMC  maintenance,  logistic, 
and  supply  system.  Environment  and  specialty  engineering  analysis  make  up  the  non¬ 
functional  portion  of  the  objective  hierarchy. 


When  the  functional  and  non-functional  requirements  converge.  Measures  of 
Effectiveness  (MOEs)  are  developed  for  all  requirements  to  make  up  the  Objective 
Hierarchy®.  These  MOEs  are  the  basis  of  a  system  level  performance  specification  or 
capabilities  development  document  (ODD).  However,  for  the  purposes  of  this  analysis, 
an  Objective  Hierarchy  will  be  sufficient  to  complete  the  methodology.  The 
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requirements  analysis®  provides  the  complete  linkage  between  the  measures  of 
effectiveness  and  allocation  to  a  sub-system  developed  from  the  physical  architecture. 
This  linkage  is  the  key  to  future  refinements  of  the  system  beyond  the  early  concept 
phases  of  the  program.  This  helps  provide  a  foundation  for  good  systems  engineering 
and  a  backbone  for  sound  program  management. 

From  the  high  level  description  of  the  sub-systems,  (defined  from  the  architecture 
decomposition  and  the  physical  architecture)©,  the  system  is  then  decomposed  into  the 
next  layer  of  abstraction,  where  actual  hardware  elements  are  assigned  to  the  physical 
architecture.  Ideally  all  the  system  needs,  defined  in  the  objective  hierarchy,  are 
represented  by  the  hardware  elements.  Alternative  Generation®  is  developed  using  a 
morphological  box  or  similar  brainstorming  exercise  to  ensure  all  ideas  are  considered. 
Alternatives  are  screened  for  feasibility  and  grouped  together  to  make  a  complete  system 
as  described  in  the  physical  architecture.  At  this  point  in  the  methodology,  the  hardware 
chosen  to  make  up  the  system  can  be  analyzed  for  cost  ®  and  risk®  to  contribute  to  the 
alternative  analysis®.  A  completed  alternative  analysis  will  result  in  a  recommended 
alternative.  This  methodology  is  an  iterative  process  that  is  the  foundation  for  future 
systems  engineering  work  as  the  system  undergoes  further  definition  to  the  component 
and  sub-component  level.  This  methodology  also  provides  the  necessary  roadmap  and 
traceability  when  requirements  evolve  as  the  needs  of  the  Marine  Corps  evolve. 
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II  PROBLEM  DEFINITION 


During  the  Problem  Definition  phase  of  the  design  process  the  team  focused  upon 
interdisciplinary  methods  for  defining  a  vision  of  what  constitutes  a  system,  in  terms  of 
meeting  the  stakeholder  needs.  Problem  definition  is  crucial  as  it  establishes  the  basis  for 
all  subsequent  analysis  and  evaluation  of  the  project. 

A  PROBLEM  STATEMENT 

Joint  Requirements  Oversight  Counsel  Memorandum  071-08  directs  for  U.S. 
Forces  to  explore  alternatives  for  enhanced  communications  and  networking.  It  also 
identifies  the  need  for  an  enhanced  Blue  Force  tracking  capability  for  Command  and 
Control  (C2),  and  Situational  Awareness  (SA)  that  supports  seamless  exchange  of 
information  between  operating  forces  in  joint  operational  areas.  (Note:  Blue  Force 
tracking  is  a  United  States  military  term  used  to  denote  a  Global  Positioning  System 
(GPS)  enabled  system  that  provides  military  commanders  and  forces  with  location 
information  about  friendly  military  forces). 

This  memorandum  addresses  a  need  to  promote  sharing  of  secure/unsecured 
position  location  information  and  relevant  SA  information  between  combatant 
commanders,  services,  and  agencies.  Senior  level  leadership  has  determined  that  squad 
level  and  below  communications  are  mission  dependent  and  may  have  varying  levels  of 
classification;  therefore,  the  telecommunications  devices  used  by  the  squad  must  also  be 
able  to  satisfy  all  missions.  In  addition,  current  programs  fall  short  of  supporting  a 
MERS  net  centric  capability  today.  The  challenge  now  for  the  Marine  Squad  Leader  is 
executing  the  mission  effectively  as  a  maneuvering  element  of  the  rifle  platoon  with  the 
existing  “status  quo”  communications  solution.  The  primitive  need  of  this  project 
focuses  on  finding  a  system  that  could  adequately  address  the  command  and  control  and 
situational  awareness  capability  required  by  the  Marine  Corps. 
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B  NEEDS  ANALYSIS 


1.  Stakeholder  Analysis 

Requirements  are  generally  considered  the  cornerstone  of  the  systems  engineering 
process.  Originating  requirements  are  those  requirements  initially  established  by  the 
system  stakeholders  with  the  help  of  the  systems  engineering  team.  The  systems 
engineering  design  process  is  a  mixture  of  establishing  requirements  to  define  the  design 
problem  and  portioning  the  physical  resources  of  the  system  into  components  that 
perform  functions  that  meet  the  requirements.  Many  important  decisions  are  made  by  the 
systems  engineering  team  that  will  ultimately  affect  the  performance  of  the  system  and 
the  satisfaction  of  the  stakeholders.  (Buede,  2000) 

A  stakeholder  analysis  was  conducted  to  gain  a  better  understanding  of  the  needed 
capability  and  determine  customer  desires  from  a  holistic  view,  with  the  goal  of 
addressing  joint  and  service  requirements. 

a.  Stakeholders 

The  stakeholders  that  have  a  vested  interest  have  been  identified  from  the 
following  groups  of  clients,  decision-makers,  sponsors,  users,  and  analysts.  The  key 
stakeholders  for  this  undertaking  were  determined  to  include,  but  are  not  limited  to  the 
following  organizations: 

(i)  Policy  &  Decision  Makers 

■  Joint  Forces  Command  (JFCOM)  oversees  joint  services  transformation 
including  Concept  Development  and  Experimentation,  Training, 
Interoperability  and  Integration  according  to  Unified  Command  Plan  (UCP) 
(2008).  JFCOM  helps  develop,  evaluate,  and  prioritize  the  solutions  to  the 
interoperability  problems  plaguing  the  joint  war  fighter. 

■  Headquarters  Marine  Corps  (HQMC)  Command,  Control,  Communications 
and  Computers  (C4)  is  responsible  for  the  planning,  directing,  coordinating 
and  overseeing,  C4  and  Information  Technology  (IT)  capabilities  that  support 
the  warfighting  functions,  and  influences  the  combat  development  process  by 
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establishing  policy  and  standard  for  developing  the  enterprise  architecture  to 
achieve  Joint  and  combined  interoperability. 

(http://www.hqmc.usmc.mil/PP&0) 

■  HQMC  Plans  Policies  &  Operations  (PP&O)  is  responsible  for  the 
coordinating  the  development  and  execution  of  service  plans  and  policies 
related  to  the  structure,  deployment  and  employment  of  Marine  Corps  forces. 
(http://www.hqmc.usmc.mil/PP&0) 

(ii)  User  Representatives 

■  Marine  Corps  Squad  Leader  is  responsible  for  carrying  out  missions 
communicated  to  him  by  his  Platoon  Commander  through  the  effective 
management  of  the  squad  and  squad  resources. 

■  Marine  Corps  Combat  Development  Command  (MCCDC)  is  responsible  for 
the  development  of  fully  integrated  Marine  Corps  war  fighting  capabilities; 
including  doctrine,  organization,  training  and  education,  materiel,  leadership, 
personnel,  and  facilities,  to  enable  the  Marine  Corps  to  field  combat-ready 
forces,  (https://www.mccdc.usmc.mil). 

(iii)  Acquisition  Agents  and  System  Developers 

■  Marine  Corps  Systems  Command  (MCSC)  Deputy  Commander,  Systems 
Engineering,  Interoperability,  Architectures  and  Technology  (DC-SIAT) 
serves  as  the  principal  agent  for  acquisition  and  oversees  the  development  of 
the  complex  systems  that  equip  today’s  Marine  force. 
(http://www.marcosyscom.usmc.mil/sites/siat). 

(iv)  Evaluators  &  Analysts 

■  Marine  Corps  Operational  Test  &  Evaluation  Activity  (MCOTEA)  provides 
operational  testing  and  evaluation  on  behalf  of  the  Marine  Corps  and  conducts 
additional  testing  and  evaluation  as  required  to  support  the  Marine  Corps 
mission  to  man,  train,  equip,  and  sustain  a  force  in  readiness. 
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■  Marine  Corps  War-fighting  Laboratory  (MCWL)  improves  current  and  future 
naval  expeditionary  warfare  capabilities  across  the  spectrum  of  conflict  for 
current  and  future  operating  forces. 

b.  Stakeholder  Approach 

The  approach  for  capturing  the  stakeholder  needs  included  questionnaires, 
interviews,  and  research  that  determine  the  values  germane  to  transforming  the  primitive 
need  statement.  A  questionnaire  (in  APPENDIX  D)  was  designed  to  facilitate  describing 
the  problem  from  points  of  view  from  all  stakeholder  groups.  The  stakeholders  provided 
responses.  Research  of  source  documents  was  also  incorporated  within  an  affinity 
diagram,  which  was  used  to  arrange  and  group  ideas. 

c.  Policy  Makers 

Research  of  policy  documents  produced  a  joint  operational  capability  with  respect 
to  the  problem  space  of  marine  expeditionary  rifle  squad  communications.  The  JROC 
approved  position  location  information  (PLI)  classification  and  security  policy  for  blue 
force  tracking  system  determines  a  need  for  C2,  and  situational  awareness  at  the  edge  of 
the  battle  field.  The  policy  guidance  for  the  marine  squad  communications  system  is 
traceable  back  to  the  following  joint  capability  requirements: 

■  Forces  using  two-way  C2/SA  systems  must  protect  aggregated  BFT  PLI  data 
at  the  confidential  or  higher  level  of  classification.  All  devices  operated  at 
this  level  that  transmit  and  receive  aggregated  PLI  data  must  be  designed  to 
protect  this  data  to  a  level  merited  by  classified  information. 

■  PLI  classification  is  mission  dependent.  PLI  may  be  either  unclassified  or 
classified  depending  on  mission  and  combat  conditions. 

■  Friendly  force  units  operating  in  a  battlespace  or  other  combatant  commanders 
declared  operating  area  must  employ  capabilities  that  protect  exploitable 
(nonperishable,  survivable)  PLI  data  as  classified. 

■  Both  transmission  security  and  crypto  logical  security  are  necessary  to  protect 
a  PLI  system  or  family  of  systems  from  exploitation. 
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■  PLI  systems  should  be  designed  to  optimize  both  types  of  security.  Combatant 
Commanders  may  establish  particular  mission-dependent  guidance  applicable 
to  generation,  transmission,  and  handling  of  PLI  data  for  forces  operating  in 
the  air,  space,  maritime,  and  ground  domains. 

■  Forces  may  protect  one-way,  non-aggregated  PLI  data  to  less  than  secret,  but 
as  a  minimum  must  protect  to  the  level  merited  for  controlled  unclassified 
information  (CUI),  and  certified  by  NSA. 

d.  Acquisition  Agent  Feedback 

Examination  of  Marine  operating  concept  source  documentation  illuminated  an 
operational  capability  that  meets  the  needs  of  the  USMC  for  MERS  communications. 
Specifically,  squads  require  advanced,  integrated,  and  multi-purpose  systems  for 
communication,  location,  and  identification.  These  assets  must  be  capable  of  calling  for 
fires  and  coordinating  with  other  physically  separated  units  moving  throughout  an 
expanded  battlespace.  Focused,  realistic  and  demanding  training  is  probably  the  single 
most  critical  element  for  development  of  rifle  squad  capabilities.  The  squad  leader  and 
fire  team  leaders  require  more  robust  and  expanded  training  in  several  critical  areas  to 
ensure  they  develop  the  independence,  self-reliance,  and  confidence  to  handle  more 
demanding  situations.  Maneuver  units  and  fire  support  assets  must  be  able  to  identify 
small  friendly  units  distributed  across  the  battlespace.  (MERS  Draft  Tactical  Operating 
Concept,  2009).  The  following  were  recommendations  from  the  acquisition  agents: 

■  Develop  an  Initial  Capability  Document  (ICD)  for  MERS 

■  Create  a  formal  Program  Objective  Memorandum  (POM)  initiative  for  MERS 

■  Continue  dialog  with  the  operational  forces  to  identify  evolving  needs 

■  Continue  socializing  the  concept  to  LFSMC  leadership 

■  Develop  Capability  Development  Documents  (CDDs)  to  identify  the  highest 
priority  required  capabilities  as  determined  by  the  war  fighter  input 

e.  Clients  and  Users  Feedback 
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Questionnaire  responses  from  the  user  community  gave  insight  on  the 
communications  solution  of  today,  and  provided  feedback  on  additional  capability 
desired  by  the  end-user.  The  current  communication  capability  fielded  has  two  radios  for 
the  squad  leader  to  conduct  communications  vertically,  and  horizontally.  The  first  radio  is 
a  AN/PRC-152  with  NSA  approved  encryption  for  voice  only  communications  between 
the  squad  leaders  and  platoon  commander.  The  second  is  an  Interim  Intra-Squad  Radio 
(IISR  (AN/PRC-153))  with  commercial  encryption  for  voice  only  communications 
between  squad  leaders  and  squad  members.  This  communication  approach  has  its 
drawbacks  from  an  integration  stand  point  because  of  the  additional  devices  required  to 
conduct  communication  during  missions. 

The  following  desired  capabilities  were  identified  by  the  users: 

■  A  tracking  capability  for  infantry  units  is  a  necessity  for  situational  awareness 
back  to  command. 

■  The  Marine  squad  missions  now  call  for  a  non-terrestrial  multiband  waveform 
based  capability  for  interoperability  between  various  communications  devices 

■  A  common  encryption  scheme  to  reduce  logistical  requirements 

■  A  data  information  sharing  capability  is  needed  for  non-verbal  information 
exchange 

■  Interoperability  between  coalition,  service  elements,  and  other  agencies  for 
joint  missions 

■  Ruggedized  equipment  with  enhanced  durability  for  different  operational 
environments. 

■  Training,  ease  of  use,  ergonomics,  for  communicating  rapidly 

■  Current  implementation  requires  multiple  devices  to  conduct  operations. 

/  Evaluators  and  Analysts  Feedback 

The  project  team  conducted  a  Human  Factors  Engineering  Analysis  on  the 
currently  deployed  primary  squad  level  radio  (AN/PRC- 1 52)  to  determine  the 
usability  from  a  Squad  Leader  perspective.  The  goals  of  the  analysis  were  to  identify 
causes  of  increased  human  error,  task  time,  and  workload. 
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Today  the  USMC  Squad  leader  is  mentally  over-tasked  and  physically  over¬ 
burdened.  The  execution  of  the  missions  requires  communicating  the  orders  for  the 
tactical  employment,  fire  discipline,  and  fire  control  of  the  squad  during  close 
engagement  with  the  enemy.  The  analysis  recognized  human  factors  challenges  to 
include: 

■  There  is  no  formal  training  provided  to  the  user  for  the  IISR  (AN/PRC- 153) 
radios.  The  platoon  level  and  below  (Users)  are  often  given  on-site  informal 
training  as  needed  or  during  exercises  and  are  given  a  comprehensive  manual 
with  the  radio,  for  reference. 

■  The  Liquid  Crystal  Display  (LCD)  on  each  of  the  fielded  radios  lacks  an 
antiglare  protection  which  makes  the  black  text  on  a  green  or  gray  background 
hard  to  read  in  bright  sunlight.  In  addition,  both  radios  use  different  font  sizes 
and  the  smallest  font  characters  are  extremely  difficult  to  view  unless  the 
radio  is  held  closer  to  one’s  face. 

■  The  weight  and  size  of  the  AN/PRC  152  radio  is  approximately  2.6  lbs. 
without  the  whip  antenna,  and  approximately  3.3  lbs.  with  the  antenna.  This 
device  is  top  heavy  when  held  in  the  middle  with  one  hand,  which  creates  a 
torque  effect  on  the  wrist.  A  holster  is  used  primarily  once  the  radio  is 
configured. 

■  The  channel  selection  and  transmission  switch  are  difficult  to  view  in  low 
level  lighting.  The  switch  is  not  illuminated  for  night  missions,  and  the 
encryption  type  that  the  radio  uses  is  not  intuitive. 

2.  Affinity  Diagram 

The  results  of  the  team’s  research  and  interviews  with  key  stakeholders  enabled 
the  needs  analysis  effort  and  resulted  in  focused  information  gathering.  An  Affinity 
Diagram  is  used  to  organize  and  group  information.  The  process  began  with  the 
generation  of  feedback  from  the  stakeholder  interviews.  The  feedback  was  displayed  for 
the  sole  purpose  of  searching  through  the  data  with  the  premise  that  similar  ideas  were 
grouped  together  and  unrelated  feedback  established  new  groups.  The  ideas  that  are 
similar  were  added  to  the  same  groups,  and  unrelated  feedback  established  new  groups. 

-  19- 


The  '"Improvement  ofUSMC  squad  to  share  and  communicate”  affinity  diagram  is  seen 
in  Figure  6  below. 


Cross  Domain  Challenges 


Security 

Challenges 


System 

Voice  Data 

Requirement 

Interoperability 

Challenges 

Challenges 

Service  element 
operational 
difference 

Service  element 
mission 
requirement 
differences 

Service  element 
doctrine 
differences 

Lacks 

implementation 

strategy 

Squad  leader 
requires  different 
radios  for 
communications 

Various  existing 
status  quo 
(SINGARS, 
EPLARS)  solutions 

Antenna  impeded 
by  ECM 

No  vision  or  future 
roadmap  for  MERS 

Current  material 
solutions  not 
operational  feasible 

No  requirement  for 
a  squad  integrated 
capability 

No  common 
encryption  doctrine 

Current  material 
solution  not 
technically  mature 

Lack  of  encryption 
and  standard  PLI 
addressing 


Lack  of  common 
communication 
equipment 
standard 


No  common 
information 
exchange  for 
service  element 


Figure  6  Affinity  Diagram 

3.  Effective  Needs  Statement 

After  fully  examining  the  results  of  all  of  the  needs  analysis  tools,  the  team 
developed  the  following  effective  needs  statement: 

The  Marine  Corps  requires  a  device  or  devices  that  will  equip  the  squad  leader 
and  members  with  the  ability  to  communicate  key  information  exchanges  to 
perform  their  mission.  The  communications  equipment  must  meet  doctrinal 
mandates  and  provide  reliable,  covert,  secure,  timely  and  accurate  information 
when  and  where  needed. 

Key  verbal  and  non-verbal  information  exchanges  are: 

■  Geographic  location  /  Position  Location  Information  (PLI) 

■  Mission  objectives  /  Commanders  Intent  and  Orders 

■  Personnel  status,  equipment  status,  weapons  and  ammunition 

4.  Input-Output  Model 
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The  system  must  meet  the  minimum  capability  to  transmit,  receive,  and  process 
voice  communications  with  input  via  a  microphone  and  output  via  a  speaker.  Based  on 
the  effective  need  statement  above,  the  system  must  also  provide  the  additional  capability 
to  transmit,  receive,  process,  and  display  digital  data,  in  textual  and  graphical 
representations.  For  example  the  system  must  display  and  transmit  the  member’s  PLl 
with  latitude  and  longitude  readings.  The  system  must  also  provide  additional 
networking  capabilities,  or  connectivity  in  order  to  support  a  suite  of  other  netted  sub¬ 
systems,  Command  &  Control  (C2)  and  Situational  Awareness  (SA)  systems  or  devices, 
(such  as  a  personal  processing  device,  a  BFT  system.  Marine  health  monitoring  devices 
and  weapon  monitoring  devices,  etc.).  These  additional  devices  must  be  able  to  interface 
with  the  system  but  are  not  considered  part  of  the  transmission  system.  The  devices  must 
operate  in  combat  conditions,  requiring  the  ability  to  control  light  emitted  and  the  ability 
to  increase  or  decrease  audio  output. 

In  Error!  Reference  source  not  found,  below  the  team  developed  a  simple  view 
of  the  inputs  and  outputs  of  the  communication  system  at  the  squad  level.  This  view 
provides  a  partial  list  of  controllable  and  uncontrollable  inputs  and  their  respective 
outputs  after  the  system  has  processed  them.  This  list  is  not  all  inclusive  but  is  a  focused 
set  of  parameters  based  on  existing  communications  systems  in  the  current  operational 
environments  today.  Currently  the  fielded  system  only  processes  voice  communications 
as  the  input  into  an  audible  output. 

Ultimately  the  squad  communications  system  will  provide  the  squad  leader  the 
ability  to  receive,  transmit,  generate  and  process  both  voice  and  digital  data  sets  of 
information  simultaneously,  (i.e.  formatted  message  sets,  free  text  or  chat,  GPS 
coordinates,  etc.). 
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Figure  7:  Input  -  Output  Model 

For  example,  the  system  should  receive  a  digital  image  with  annotated  text  while 
the  squad  leader  is  using  his  or  her  voice  to  update  the  squad’s  current  position  to  the 
platoon  commander.  The  desired  output  of  this  example  is  an  error  free  image  received 
as  well  as  a  clear,  un-garbled  audio  message  acknowledged  by  the  platoon  commander. 
Other  parameters  listed  in  the  diagram  are  described  below: 
a.  Controllable  Inputs: 

The  operator  must  have  the  ability  to  select  one  or  multiple  channels  to 
accomplish  voice  and  data  transmissions  across  directed  radio  and  networking  channels. 
This  operation  can  be  pre-planned,  automated,  or  manually  applied  based  on  operator 
requirements. 

The  encryption  material  will  be  in  the  forms  as  designated  by  NSA  and  in  keeping 
with  common  operating  Tactics,  Techniques  and  Procedures  (TTPs).  The  physical 
inputting  of  the  encryption  algorithms  may  be  automated  or  manually  inserted. 

Data  sets  with  formatted  descriptive  elements,  such  as  Operational  Orders, 
Fragmentary  Orders,  Warning  Orders  and  Free  Text  Messages  will  be  created  or 
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published.  These  data  sets  will  be  created  or  published  by  other  Command  and  Control  / 
Situational  Awareness  (C2/SA)  devices  in  digital  formats  applicable  to  wireless 
transmissions.  For  the  purposes  of  this  project  it  will  be  assumed  that  these  C2/SA 
devices  will  interface  with  a  network  capable  radio/transmission  device. 

Additional  information  systems  relying  on  an  available  network  capable  system 
could  include  automated  Weapons  Systems  Status,  Individual  Health  Monitoring,  and 
other  systems  reporting  details  relevant  to  the  operating  environment.  Inputs  will  be 
enabled  via  networking  interfaces  like  Universal  Serial  Bus  USB,  Ethernet,  and  Serial 
ports. 

b*  Uncontrollable  Inputs: 

With  ah  digital  transmission  systems,  the  introduction  of  networking  anomalies, 
audio  feedback,  environmental  effects,  and  electromagnetic  effects  must  be  anticipated 
and  the  transmission  system  must  be  able  to  overcome  and  adapt  to  the  challenging 
networking  environment  as  experienced  on  the  battlefield. 

c.  Controllable  Outputs: 

Outputs  will  be  enabled  via  networking  interfaces.  As  a  result  of  the  ability  to 
transmit  and  receive  digitized  voice  and  data,  the  system  output  will  be  audio  or  data 
elements  translatable  by  the  system  or  netted  sub-systems.  These  received  and  processed 
data  and  voice  elements  will  result  in  individual  and  unit  C2/SA  capabilities.  The  voice 
digital  outputs  will  be  formatted  for  direct  audio  output  to  speaker  system.  The  data 
digital  outputs  will  be  formatted  for  direct  translation  to  connected  individual  C2/SA 
devices.  At  a  minimum  the  system  must  be  able  to  transmit  process  and  receive  all 
formatted  audio  transmissions  and  formatted  position  location  information  (PLI). 

d.  Uncontrollable  Outputs: 

Cross-talking  circuits,  network  interruptions,  garbled  or  unreadable  data  and  other 
data  elements  can  be  expected  for  devices  operating  in  this  environment.  The  system 
must  be  able  to  overcome  these  obstacles  but  the  processing  and  data  formatting  are  again 
resident  in  the  network  sub-systems  and  not  a  required  capability  of  the  communication 
system. 
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The  10  model  in  Figure  7  provided  the  SE  Team  another  tool  that  described  the 
basic  information  flow  of  data  and  the  basic  functions  expected  of  the  communications 
system  at  the  squad  level.  In  other  words  the  team  used  the  10  model  to  determine, 
‘What  does  the  system  need  to  do?’  rather  than  try  to  resolve  ‘How  does  the  system  do 
it?’  The  description  of  the  system  then  allowed  the  team  to  move  forward  into  the 
functional  analysis. 
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Ill  DESIGN 


A  FUNCTIONAL  ANALYSIS 

The  end  state  of  the  functional  analysis  was  to  establish  an  operational,  functional, 
and  physical  architecture  of  the  squad  communication  system  in  order  to  provide 
traceability  to  the  user  requirements  and  operational  context  of  the  system.  This  is 
accomplished  through  several  decomposition  iterations  of  the  three  architectures 
throughout  the  systems  engineering  methodology.  All  three  architectures  represent  the 
logical  model  that  D.M.  Buede  describes  as  the  transformation  of  inputs  into  outputs. 
(Buede,  2000).  Through  several  iterations,  the  logical  model  is  better  defined  at  lower 
levels  of  abstraction.  These  lower  levels  of  abstraction  describe  the  intricate  nature  of  the 
system.  With  well  defined  logical  models,  the  system  description  can  evolve  when  the 
environment,  requirement,  or  operational  context  changes  to  maintain  relevance.  The 
logical  models  were  developed  with  a  tailored  Integration  Definition  for  Function 
Modeling  (IDEF)  technique  to  graphically  convey  these  relationships  of  inputs  and 
outputs.  (National  Institute  of  Standards  and  Technology,  1993). 

The  three  architectural  views  of  the  squad  communication  system  are  essential  to 
form  the  context  and  objectives  of  the  system.  The  functional  and  physical  architectures 
closely  followed  the  definition  established  by  D.M.  Buede  as  a  decomposition  of  the 
function  to  which  the  system  needs  to  perform  in  order  to  meet  the  needs  of  the 
operational  architecture.  (Buede,  2000).  The  operational  architecture  used  in  the  analysis, 
which  is  consistent  with  D.M.  Buede’s  three  architectural  view  framework,  was  a  hybrid 
development  based  more  closely  to  the  Department  of  Defense  Architectural  Framework 
(DODAF)  Operational  View.  This  operational  architecture  approach  improved 
traceability  to  the  system  of  systems  architecture  from  the  MERS  ICD  and  architectures. 
The  MERS  system  of  systems  architecture  (Figure  8)  becomes  the  platform  to  align 
functions  performed  by  the  Marines  within  the  operational  context.  A  hybrid  approach 
ensured  consistency  and  traceability  to  the  larger  system  of  systems  view. 
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Figure  8:  MERS  System  of  Systems  Architecture 

1.  Operational  Architecture 

The  Operational  Architecture  provides  the  purpose  of  the  system  within  the 
operational  context.  The  Operational  Architecture  is  the  graphical  decomposition 
consistent  with  the  DoDAF  Operational  View  Three  (OV-3)  which  describes  the 
relationships,  information  flow,  and  information  content.  (Wisnosky,  2006).  These  are 
the  critical  information  exchanges  that  the  communication  system  must  process  to  carry 
out  the  missions  defined  in  the  MERS  Architecture.  (MERS  Architecture  Final  Practicum 
Project  Report,  June  2008).  Missions  are  defined  in  this  study  as  the  tasks,  together  with  a 
purpose,  that  clearly  indicate  the  unit’s  actions  to  be  taken.  (“Joint  Publication,”  2009). 
The  Operational  Architecture  defines  the  required  minimum  communication  messages 
that  the  Marine  Squad  Leader  must  process  to  provide  command  and  control  of  the  squad 
fire  teams  and  the  necessary  communications  to  higher  headquarters.  This  information 
exchange  contributes  to  the  Common  Tactical  Picture  (CTP)  during  all  missions. 

The  required  communication  messages  and  functions  used  for  the  Operational 

Architecture  were  allocated  and  decompose  from  the  higher  level  communication 
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function  in  the  MERS  Architecture.  The  Operational  Activity  Model  (OV-5)  (See 
APPENDIX  C)  provided  the  activities  or  functions,  while  the  Operational  Information 
Exchange  Matrix  (OV-3)  (See  APPENDIX  C)  provided  the  information  exchange  or 
communication  messages  required  to  perform  these  functions.  (MERS  Architecture  Final 
Practicum  Project  Report,  June  2008).When  the  OV-3  and  OV-5  communications 
functions  were  developed  in  modified  IDEE  models  the  inter  and  intra-nodal 
relationships  helped  shape  the  necessary  functions  to  process  the  communication 
messages  effectively.  For  example,  a  majority  of  messages  in  the  operational  architecture 
require  a  geographic  position  of  the  squad  and  fire  team.  Therefore  at  the  system  view, 
the  communication  system  needs  to  have  a  global  position  function  to  carry  out  the 
operational  function  or  needs  a  defined  interface  to  another  MERS  system  that  will 
perform  that  function.  Functions  such  as  target  location,  ammunition  status,  and 
equipment  status  were  allocated  to  other  MERS  systems,  and  are  not  within  the  boundary 
of  the  communication  system. 

The  operational  view  was  also  used  to  define  the  different  levels  of  classification 
required  when  sending  messages.  The  need  for  cryptographic  material  was  defined  in  the 
problem  definition,  but  the  operational  architecture  provides  a  mental  model  of  the 
relationships  for  each  level  of  classification  required.  Figure  9  shows  the  inter-nodal 
diagram  of  the  Marine  squad  with  the  different  levels  of  cryptographic  material  needed  to 
provide  secure  communications.  (MERS  Architecture  Final  Practicum  Project  Report, 
June  2008) 
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Figure  9:  Operational  View  Inter-nodal  Diagram 

The  Squad  Communication  System  Operational  View  AO  (Figure  10)  models  the 
inputs  and  outputs  of  the  various  messages  required  for  the  squad  to  be  an  effective  part 
of  the  CTP  and  supply  sufficient  command  and  control  of  the  squad.  The  messages 
identified  in  Figure  10  are  the  minimum  set  of  structured  messages.  Communication 
takes  many  forms  and  cannot  be  accurately  accounted  for  in  the  system,  but  can  be 
grouped  sufficiently  under  the  communication  messages  modeled. 


-28- 


PLT  Commander  Guidance _ 

PLT  Geographic  position _ 

PLT  Mission  Objectives/  FRAGO 

PLT  Fire  Control  Plan _ 

PLT  Friendly/enemy  location 


AJS  Friendly/enemy  location 
AJS  Mission  Objectives 

AJS  Geographic  position 

ACS  Geographic  position 

ACS  Friendly/enemy  location 

AMCS  Geographic  position 

AMCS  Mission  Objectives 

AMCS  Friendly/enemy  location 


FSCC  Fire  Support  Response 
Airborne  Fire  Notification 
Mech-Armor  Fire  Notification 
NSFS  Fire  Notification 
FSCC  Fire  Notification 


Crypto 

Classification 

FT  -  Fire  Team 

Type  1 

AJS  -  Adjacent  Joint  Squad 

Type  2 

ACS -Adjacent  Coalition  Squad 

AMCS-Adjacent  MC  Squad 

None 

PLT  -  Platoon  Leader 

Process  Squad 
Leader 

Communication  / 
Information 


A1 


SQD  Geographic  Position _ 

SQD  Friendly  Locations _ 

SQD  Members  health _ 

SQD  Provision  Status  Report _ 

SQD  CASEVAC 

SQD  Fire  Support  Request _ 

SQD  Geographic  Position 

SQD  Enemy  Locations _ 

SQD  Mission  Objectives /Frago 

SQD  Situation  Update 

SQD  Terminal  Weapons  Guidance -Airborne  Assets 

SQD  Terminal  Weapons  Guidance  —  Mech-Armor  Support 

SQD  Terminal  Weapons  Guidance -NSFS  Group _ 

SQD  Terminal  Weapons  Guidance -FSCC 

SQDL  Fire  Notificaiton 
SQDL  Mission  Provision  Requirement 
SQDL  SMEAC  Brief 
SQDL  SMEAC  detail  request 
SQDL  CMD  Execute  Mission 
SQDL  Tactical  Commands 
SQDL  Terminal  Weapons 
Guidance  —  Secure  Perimeter 
SQDL  Fire  Support  Request 
-Assault  Enemy  Position 


SQDL  Command  to  Fire' 

SQDL  Friendly  Locations ' 

SQDL  Enemy  Locations' 

SQDL  Fire  Control  Plan ' 

SQDL  Causality  Status  Report' 


Process  Fire 
Team 

Communication 
/  Information 


A2 


FT  Geographic  position _ 

FT  Enemy  Location  Report _ 

FT  Situation  Update 

FT  Ammunition  Resupply  Request _ 

FT  MEDEVAC  Request  FT  CASEVAC _ 

FT  Equipment  Status _ 

FT  Obstacle  Report _ 

FT  Provision  Status  Report  -  Other _ 

FT  Tactical  Situation -Coordinate  Manueuver _ 

FT  Tactical  Situation  -  Force  Protection  Measurements 

FT  Fire  Fight  Status  -  Coordinate  Fire  Support _ 

FT  Fire  Fight  Status  -  Secure  Perimeter _ 

FT  Causality  Report _ FT  Members  health _ 

FT  Provision  Status  Report -Ammo 


View:  Operational 

Node:  AO 

Title:  Squad  Communications 

1  of  1 

Figure  10:  IDEF-O,  Operational  View,  AO 
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The  primary  operational  function  for  the  squad  communication  system  is  to 
Process  Squad  Communication/Information.  This  can  be  decomposed  into  two  functions: 
Process  Squad  Leader  Communication/Information  and  Process  Fire  Team 
Communication/Information.  It  is  assumed  that  both  the  squad  leader  and  fire  team  will 
have  common  systems  and  equal  capability  to  process  messages.  The  inputs  to  the  squad 
leader  are  messages  across  the  range  of  nodes  depicted  in  Figure  9.  This  squad  leader 
function  transforms  messages  into  actions  to  perform  the  required  missions  of  the  Marine 
Squad.  The  required  missions  were  defined  as  functions  at  the  next  layer  of  abstraction 
as  seen  in  Figure  11  Operational  View  Al.  By  doing  a  complete  decomposition,  all 
required  messages  to  perform  the  mission  function  were  identified. 

These  communication  messages  are  not  defined  as  voice  or  data,  but  have  the 
same  information  attributes  regardless  of  the  message  form  transmitted.  The  forms  will 
remain  generic  throughout  the  functional  decomposition  in  order  to  allow  an  open 
approach  to  alternative  generation.  Depending  on  the  alternative,  either  form  may  be 
used.  The  Operational  View  Al  (Figure  11)  decomposes  block  Al  to  four  functions: 
Plan  Mission,  Control  Mission,  Report  Mission  Status  to  Higher  Headquarters,  and 
Organize  Consolidation  /  Reconstitution. 

The  complete  Operational  Architecture  is  located  in  APPENDIX  E.  Since  the 
Fire  Team  is  the  major  action  unit  for  the  mission,  the  A2  block  was  decomposed  to  the 
next  level  of  functional  abstraction.  At  the  fire  team  level,  the  focus  was  limited  to 
Marine  squad  missions  of  Movement  to  Objective  (by  foot).  Linkup,  Reinforce,  Passage 
of  Lines,  Infiltration,  and  Obstacle  Crossing/Reduction  as  defined  by  the  MERS 
Architecture  OV-5.  Other  MERS  missions  of  Movement  to  Objective  via  Ground, 
Amphibious,  and  Air  Vehicles  were  not  evaluated  because  it  is  assumed  the  host  vehicle 
will  support  the  required  communication  functions  until  the  squad  is  dismounted. 
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View:  Operational 

Node:  A1 

Title:  Squad  Leader  Communications 

1  of  1 

Figure  11:  lDEF-0,  Operational  View,  A1 


2.  F unctional  Architecture 

The  operational  view  defined  the  communication  messages  exchanged  for  each 
mission.  The  functional  architecture  defines  how  the  system  will  process  those 
communications  messages.  The  functional  architecture  will  be  allocated  to  the  physical 
architecture  and  will  define  the  squad  communication  sub-systems. 

The  Functional  Architecture  AO  (Figure  12  )  was  used  to  answer: 

■  How  will  the  system  processing  incoming  messages,  decipher  data,  and 
convey  to  the  user? 

■  How  the  system  will  generate  the  required  data  and  send  messages  to  the 
various  nodes  described  in  the  Operational  View  Inter-nodal  diagram? 

■  What  are  the  required  internal  and  external  interfaces? 
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View:  Functional  Node:  AO  Title:  Squad  Communication  System 


Figure  12:  IDEF-0,  Functional  View,  AO 
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The  system  was  then  decomposed  into  the  following  functions: 

■  Receive  Communication  Information  (Al)  includes  receiving  the  signal  / 
waveform,  and  demodulation  of  the  signal  into  an  appropriate  form  for 
processing. 

■  Process  Communication  Information  (A2)  includes  the  determination  of  the 
type  of  communication  (I,  II,  or  clear  ),  decryption  of  the  communication  if 
needed,  processing  of  the  incoming  or  generated  communication,  storage  of 
data  for  later  use,  storage  of  the  encryption  of  key  material  (I  or  II),  and 
finally  the  re-encryption  of  the  communication  for  later  transmission. 

■  Generate  Communication  Information  (A3)  generates  the  required 
communication  information  in  either  data  or  voice  communication  and 
modulated  the  input  for  communication  processing. 

■  Convey  Information  to  User  (A4)  converts  the  signals  processed  in  the 
systems  and  either  displays  the  information  or  broadcasts  the  voice 
information  to  the  user. 

■  Transmit  Communication  Information  (A5)  is  the  inverse  of  the  receive 
communication  in  which  the  signal  is  modulated,  amplified,  and  transmitted. 

■  Provide  Power  (A6)  provides  the  inherent  capability  required  to  facilitate  the 
other  functions.  This  assumes  that  the  system  must  be  self-sufficient  and  not 
allocated  to  another  system  within  the  MERS  concept. 

3.  Physical  Architecture 

The  Physical  Architecture  allocates  the  functions  from  the  Functional 
Architecture  to  sub-systems  which  are  further  defined  as  actual  hardware  or  software 
components.  This  allocation  also  defines  what  the  sub-system  is  required  to  perform  to 
make  the  system  operationally  effective.  Most  functions  have  a  one-for-one  traceability 
to  the  physical  architecture  with  the  exception  of  the  receiver  /  transmitter  sub-system 
(Figure  13). 
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Figure  13:  Traceability  from  Function  to  Sub-system 

The  Physical  Architecture  (Figure  14)  was  derived  from  the  functional  trace 
performed  above  and  can  be  used  as  simple  program  Work  Breakdown  Structure  (WBS). 
The  elements  are  generic  descriptions  of  the  key  sub-systems  which  will  eventually  be 
decomposed  to  hardware,  software,  and  human  components  later  during  system  design. 


I  View:  Physical  [Node:  [Title:  Physical  View:  Squad  Communication  System  |  1  of  1  | 

Figure  14:  Physical  Architecture 

The  Functional  Architecture  is  related  to  both  the  Objective  Hierarchy  and  Physical 
Architecture  and  traceable  to  both  products  (See  section  1I1A2  above) 
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B  VALUE  SYSTEM  DESIGN 


In  order  to  determine  the  evaluation  measures  important  to  the  Marine  Squad 
Leader,  the  team  met  with  members  of  the  Marine  Expeditionary  Rifle  Squad  (MERS) 
program  office  staff  The  group  created  a  list  of  attributes  for  the  new  system  as  depicted 
in  Table  1:  System  Attributes 


Table  1:  System  Attributes 


Weight 

Volume 

Capability 

Ease  of  use 

Battery  duration/life 

Durability 

Voice 

Text/data/images 

Anti-spoof 

Redundancy 

Security 

Bandwidth 

Reliability 

Range  (miles) 

Easy  to  learn 

Easy  to  remember 

Size/transportable 

Status  Indicators 

Commonality 

Modularity 

Multiple 

environments 

Interoperability 

Adaptable  power 
source 

1 .  Ob j  ective  Hierarchy 

The  development  of  effective  value  criteria,  as  expressed  in  an  Objectives 
Hierarchy,  is  critical  to  successful  project  development.  The  Objective  Hierarchy  is 
intended  to  ensure  that  the  correct  objectives  and  measures  of  effectiveness  have  been 
identified  so  that  the  correct  system  is  designed  and  successfully  validated  against  the 
needs,  expectations,  and  constraints  of  the  ultimate  end  user,  the  USMC. 

2.  Value  System  Modeling 

Using  existing  documents  and  discussions  with  key  stakeholders,  USMC  subject 
matter  experts,  and  other  research  data,  previously  identified  in  this  report,  the  Team  has 
defined  the  Effective  Need  Statement  and  functional  decomposition  of  the  top  level 
functions  to  develop  the  Objective  System  Hierarchy  shown  in  Figure  16  through  19. 

The  Objective  Hierarchy  provides  a  top-down  approach  starting  with  the 
Functional  and  Non-Functional  Attributes  derived  from  the  Effective  Needs 
Statement,  (described  in  Section  IIB3),  and  subsequently  flowing  down  into  two 
major  categories  namely  Functional  and  Objective  Hierarchy  (Figure  16  and  Figure 
17)  and  Non-Functional  Attributes  and  Objectives  (Figure  18  and 
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Figure  19).  Specific  measures  of  effectiveness  are  assigned  to  each  objective  for 
Analysis  of  Alternatives  (AoA)  and  verification  purposes. 

Selection  of  the  measures  of  effectiveness  is  based  on  the  requirements  derived  from 
the  available  documentation  as  they  apply  to  the  system  along  with  other  requirements 
discovered  by  the  Team  as  part  of  Needs  Analysis.  For  example,  stakeholder  analysis  has 
identified  the  ability  to  communicate  to  both  higher  and  lower  echelons  via  one  radio  as 
one  of  the  most  important  objectives  driving  the  need  for  a  communications  system. 
Therefore  weight  and  volume  are  typical  measures  of  effectiveness  that  are  used  in  the 
decision  making  process.  Attribute  N5,  chosen  to  ensure  usability  and  human  factors  uses 
weight,  volume,  maximum  total  workload  and  operational  use  as  the  measures  of 
effectiveness  used  to  evaluate  this  attribute. 

The  system  must  be  operational  and  maintainable  in  all  types  of  climate  and  terrain 
where  Marines  deploy  or  may  deploy.  Therefore  maximum  and  minimum  temperature, 
quantity  of  rain,  snow,  ice,  and  wind  velocity  are  important  measures  of  effectiveness. 
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Attribute  N6  references  military  standards  that  state  the  environmental  requirements  and 
these  requirements  must  be  met  by  each  alternative  in  order  to  be  considered  in  this 
evaluation  in  order  to  ensure  operation  in  all  environments. 

Duration  of  power  and  percentage  of  incoming  and  outgoing  messages  processed  are 
some  of  the  other  measures  of  effectiveness  used  in  the  decision  making  process. 

Each  measure  of  effectiveness  is  depicted  in  a  box  at  the  end  of  its  corresponding 
bottom  level  function/objective.  The  measures  of  effectiveness  denoted  with  an  asterisk 
are  used  to  evaluate  the  different  alternatives  discussed  in  section  111B3  below. 

The  team  chose  the  measures  of  effectiveness  to  use  in  the  decision  making  process 
by  determining  what  data  would  provide  the  greatest  distinction  between  the  alternatives 
and  could  be  gathered  from  the  modeling  and  simulation  process  and  the  research 
sources. 


Communications  System 

Functional  Attributes 

Non-  Functional  Attributes 

2 

Figure  15:  Functional  and  Non-Functional  Attributes 

Selection  of  the  measures  of  effectiveness  is  based  on  the  requirements  derived 
from  the  available  documentation  as  they  apply  to  the  system  along  with  other 
requirements  discovered  by  the  Team  as  part  of  Needs  Analysis. 

Functions  Al,  A2,  and  A5  [Figure  16]  are  related  to  the  radio(s)  associated  with 
the  squad  leader  communications  system.  The  stakeholder  analysis  identified  the  ability 
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to  communicate  to  both  higher  and  lower  echelons  via  one  radio  as  one  of  the  most 
important  objectives  driving  the  need  for  a  communications  system.  Therefore  goals  and 
MOEs  associated  with  the  radio  system  were  focused  on  ensuring  the  radio(s)  worked  as 
multiband  radios  with  proper  encryption  and  little  to  no  errors  associated  with  the 
objective  single  radio  development. 

Function  A6  [Figure  16]  addressed  another  identified  area  of  great  importance 
based  on  analysis  and  stakeholders  desire  for  lighter  and  more  efficient  power  generation 
capability.  This  was  evaluated  by  collecting  raw  data  and  specifications  on  available 
batteries. 

Functions  A3  and  A4  [Figure  17]  are  related  to  the  information  processing 
capability  associated  with  the  integrated  communications  system.  The  goals  and  MOEs 
associated  with  these  objectives  are  to  ensure  the  user  interface  and  input/output  devices 
reduce  human  and  system  error.  Through  interviews  and  analysis  of  after  action 
comments  it  was  quite  apparent  that  the  squad  leader’s  primary  focus  cannot  be  taken 
away  from  his  tactical  tasks  to  deal  with  inaccurate  or  erroneous  information  being 
conveyed  to  him.  He  must  be  able  to  trust  the  information  and  data  being  offered  to  him 
as  factual  and  reliable  or  the  system  becomes  a  hindrance  vice  an  asset. 

Attribute  N5  [Figure  18]  deals  with  human  factors;  form  factor,  weight  ease  of 
use,  user  interface  simple  configuration  and  operation,  etc.  If  the  system’s  benefits  do 
not  satisfy  the  operator,  then  the  system  will  be  characterized  as  operationally  ineffective 
and  will  not  be  used  during  operations.  Part  of  this  attribute  was  evaluated  with  raw  data, 
a  cognitive  model  and  evaluated  by  the  team  via  a  Likert  scale. 

Attributes  N2,  N3,  and  N4  [ 
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Figure  19]  are  related  to  the  system’s  reliability,  availability  and  maintainability. 
Through  the  needs  analysis,  interviews  and  stakeholder  analysis  it  was  determined  that 
the  squad  leaders  will  only  take  equipment  to  the  field  that  they  have  full  reliance  on  and 
can  be  almost  certain  that  it  will  not  break  or  become  ineffective  during  a  mission.  The 
packed  out  load  for  a  Marine  is  near  95  pounds  already  and  near  unbearable  by  most. 
Any  additional  weight  will  only  be  acceptable  if  the  system  brings  added  utility  with 
minimal  impact  to  the  operators. 

Attributes  N1  and  N6  [ 
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Figure  19]  are  directly  related  to  a  physical  and  electronically  hostile 
environments.  The  system  must  survive  enemy  electronic  counter-measures  as  well  as 
the  rigors  associated  with  operating  in  a  combat  zone  that  promises  anything  but  a  “walk 
in  the  park.”  Attribute  N6  references  MIL-STD  810,  a  military  standard  that  defines  the 
environmental  requirements  that  must  be  met  by  each  alternative  in  order  to  be 
considered  in  this  evaluation,  thus  these  measures  were  colored  Blue  to  represent  that 
without  meeting  these  requirements,  then  the  alternative  was  discarded. 

Attributes  Al,  A5  and  N6  are  considered  to  be  the  entry  criteria  attributes.  All 
alternatives  had  to  meet  these  in  order  to  be  considered  and  thus  could  have  been  used  in 
the  feasibility  screening  process.  However,  the  team  determined  that  these  attributes  are 
unique  to  each  system  being  considered  and  thus  could  be  considered  and  used  as 
differentiating  MOEs. 
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Information 


A2 
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Communication 
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Crypto  Processing 
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Data  Memory  Storage  (Mbytes) 

Increase  crypto  processing  accurately 
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Process  Communication  messages  faster 

Message  throughput  (%)  * 

Store  enough  data  to  complete  mission 

Data  Memory  Storage  (Mbytes) 

A5 


Transmit 
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Power 
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Figure  16:  Functional  Attributes  and  Objectives 
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Audio  data 

Error  Rate  (%)* 

Latency  (ms) 

Increase  accuracy  &  timeliness 
Visual  data 

Error  Rate  (%) 

Latency  (ms) 

Decrease  Digital  Data  or  Analog  Voice 
Error  and  latency 

Error  Rate  (%)* 

Latency  (ms) 

Increase  accuracy  &  timeliness 
Audio  data 

Error  Rate  (%)* 

Latency  (ms) 

Increase  accuracy  &  timeliness 
Visual  data 

Error  Rate  (%) 

Latency  (ms) 

Modeled 

Raw  Data 

Evaluated 

Required 

- ►  - 

Functional  Attributes  Attribute  Objectives 

Figure  17:  Functional  Attributes  and  Objectives  (cont) 
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Attribute 
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Description 


Minimize  Weight 


Physical  Size  for  handheld  use 


Comprehensive  Visual  Data 


Comprehensive  Audio  Data 


Ability  &  Complexity  to 
Consume  Analog  &  Digital  Data 
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Create  Analog  &  Digital  Data 


Goal 


Measure  of  Effectiveness 


Reduce  weight  from  the  status  quo 


Weight  Reduction  (Ibs/ozs)* 


Reduce  size  from  the  status  quo 
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in  all  conditions 

Screen  Dimensions  (in) 

Readability  (Likert  Scale  1-7) 

Maximize  Quality 

Clarity  in  all  conditions 

Tone  Frequency  (Hz)) 

Gain  (dB) 

Minimize  Workload  of  operator 


Workload  assessment  rating  (1-7)* 


Easy  to  Configure,  Program,  &  Enter  Data 
Maximized  Accuracy  w/  Minimum  effort 


Avg  time  to  enter  data  (s) 


Avg  time  to  enter  crypto  (s) 


Operational  Use  (Likert  Scale  1-7)* 


Modeled 

Raw  Data 

Evaluated 

Required 

- ►  - 

Non  -  Functional  Attributes  Attribute  Objectives 

Figure  18:  Non-Functional  Attributes  and  Objectives 
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Attribute 

Description 

Goal 

Measure  of  Effectiveness 

N1 

\ 

Ensure 

EMP/EMI  Resistant 

Maintain  Operation  in  an  EMI  environment 

Increased  SNR  (dB)  Gain 

Survivability 

Jamming  Resistant 

Reduce  effects  of  jamming 

Increased  SNR  (dB)  Gain 

N2 

V 

Ensure 

Reliability 

Overall  Reliability  of 
Communications  System 

V  J 

Increase  the  mean  time  between  failure 

Mean  Time  Between  Failure  (%)* 

N3 

\ 

Ensure 

Availability 

'' 

Overall  Availability  of 
Communications  System 

Increase  Operational  Usage  /  Total  Time 

In  all  conditions 

Operational  Availability  (%) 

In  all  conditions 

N4 

\ 

Ensure 

[aintainability 

y  \ 

Overall  Maintainability  of 
Communications  System 

Reduce  MTTR 

MTTR  (Hrs) 

V  y  y 

Modeled 

Raw  Data 

Evaluated 

Required 

- ► 

Non  -  Functional  Attributes 


- ► 

Attribute  Objectives 
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Figure  19:  Non-Functional  Attributes  and  Objectives  (cont) 
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3.  Evaluation  Measures  and  Weighting 

After  finalizing  the  Functional  Hierarchy  for  the  system,  the  team  focused  on 
defining  the  key  evaluation  measures  and  weights  to  be  used  for  the  Decision  Matrix. 
The  weights  are  based  on  the  stakeholders’  inputs  that  were  discussed  earlier  in  this 
report. 


The  values  of  the  weights  were  based  on  the  subjective  assessment  by  the  team  of 
the  stakeholder  preferences.  The  team  evaluated  over  forty  measures  of  effectiveness 
that  could  be  used  as  the  foundation  for  the  weighting  factors.  After  a  thorough  review  of 
the  Needs  Analysis  and  the  stakeholder  inputs  it  was  apparent  that  the  factors  that  had  the 
greatest  effect  were  associated  with  employability.  Weight  was  selected  as  the  best  factor 
to  encompass  the  key  physical  attributes  of  the  system  (size,  weight,  and  transportability). 
Duration  of  Power  was  determined  as  the  best  factor  to  encompass  power  generation  due 
to  the  fact  that  less  duration  requires  additional  spare  power  to  be  carried.  The  other 
factors  associated  with  the  squad  leader’s  interface  to  and  reliance  on  an  integrated 
system  that  would  make  the  system  worth  adding  to  the  combat  load  due  to  the  increased 
capability  offered  to  the  squad  leader.  The  agreed  upon  weighting  for  the  seven 
evaluation  measures  are  identified  in  Table  2  below. 


Table  2:  Weighting  Factors 

Weighting  factor 
20 
15 
15 
15 
15 
10 
10 

Check  Sum  =  100 


The  team  used  these  weighting  factors  to  evaluate  the  alternatives  and  determine 
the  best  Course  of  Action  (COA)  which  is  described  later  in  the  document.  Physical 
characteristics  of  the  radio  (weight),  operational  characteristics  of  the  radio  (Power, 
Operational  use,  and  MTBF),  and  cognitive  characteristics  of  the  user  (max  total 
workload,  incoming  message  percent  processed  and  the  outgoing  messages  percent 
processed)  were  derived  and  selected  as  the  key  weighting  factors  in  this  study.  While 


Evaluation  Measures 
Weight 

Duration  of  Power 
Operational  use 
MTBF 

Max  Total  Workload 
Incoming  msg  %  processed 
Outqoinq  msq  %  processed 


Metric 

pounds 

hours 

1  though  7  scale 
% 

workload  units 

% 

% 
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there  were  other  measures,  the  seven  selected  measures  were  based  on  stakeholder  input 
and  team  analysis. 


-48- 


IV  MODELING  AND  ANALYSIS 


A  ALTERNATIVES  GENERATION 

Prior  to  selecting  products  or  solutions,  a  list  of  alternatives  must  be  generated. 
Within  the  DoD,  there  are  directives,  and  instructions  that  direct  the  SE  process  to  utilize 
other  means  of  analysis  and  evaluation,  prior  to  selecting  a  solution.  The  following 
paragraphs  describe  these  additional  evaluations. 

1.  Doctrine  Organization  Training  Materiel  Leadership  Personnel  and 

Facilities  (DOTMLPF) 

Throughout  the  SEDP,  it  was  quite  apparent  that  a  material  solution  would  be 
required  to  achieve  the  desired  squad  leader  communications  and  networking  capabilities 
as  outlined  and  described  earlier  in  this  report.  The  team  spent  a  great  deal  of  time  in 
determining  the  material  solutions  and  describing  in  detail  how  each  alternative  offers 
enhanced  and  evolving  capability  to  the  squad  leader.  All  material  solutions  being 
evaluated  for  incorporation  into  military  equipment  must  also  be  assessed  on  six  non¬ 
material  areas  that  are  defined  by  the  Defense  Acquisition  University  as  DOTLPF. 

2.  Non-material  Alternatives  (DOTLPF) 

a.  Doctrine 

The  doctrine  of  the  Marine  Corps  continues  to  evolve  and  adapt.  Doctrine 
does  not  currently  discuss  or  consider  distributed  squad  offensive  operations.  Nor 
does  it  consider  the  affects  of  connecting  and  networking  forces  for  situational 
awareness  and  command  and  control  below  the  battalion  formations.  As  the 
squad  leader  communications  and  decision  making  tools  evolve,  so  must  the 
doctrine  evolve  to  adequately  address  the  potential  battlefield  enhancements  that  a 
networked  force  can  bring  to  bear  in  “networked  operations.” 

b.  Organization 

The  current  organizational  construct  addresses  the  squad  as  the  smallest 
combat  organization.  The  squad  is  currently  organized  as  “trigger  pullers”  with  a 
“point  me  in  the  right  direction  and  let  me  go  do  the  mission”  perspective.  With 
added  C2  and  SA  capabilities  it  will  be  necessary  to  add  or  accommodate  for 
advanced  skill  sets  in  line  with  the  enhanced  information  technologies  (IT).  The 
squad  will  continue  to  be  organized  and  tasked  as  the  “trigger  pullers”  of  the 
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Marine  Corps  but  an  organizational  assessment  must  be  conducted  within  the 
current  structure  of  the  infantry  battalions  to  determine  if  the  current  company- 
platoon-squad- fire  team  organizations  continue  to  be  necessary. 

c.  Training 

As  the  IT  capability  enhancements  and  the  increased  skill  sets  are 
addressed  it  is  imperative  to  assess  current  squad  level  training.  To  the  extent 
possible,  no  IT  enhancements  should  dramatically  increase  training  requirements. 

d.  Leadership: 

Current  Marine  Corps  leadership  may  not  be  ready  or  prepared  for  squad 
level  distributed  operations.  These  operations  will  have  to  be  considered  and 
properly  reinforced  as  capabilities  are  added  and  squad  connectivity  changes 
tactics  and  the  “information  domain”  within  the  battlefield. 

e.  Personnel 

Additional  personnel  may  have  to  be  added  to  the  current  squad  table  of 
organization.  Further  assessment  must  be  considered  as  the  IT  enhancements 
become  realized  and  are  employed  effectively  at  this  level  of  distributed 
operations. 

f.  Facilities 

A  full  assessment  will  be  required  to  determine  amount  of  added  gear  and 
level  of  storage  security  required  for  garrison  and  when  embarked  on  amphibious 
shipping. 

3.  Material  Alternatives  Developed 

The  team  explored  existing,  new  and  future  alternatives  in  a  variety  of 
combinations  in  order  to  evaluate  the  capabilities  of  existing  communications  systems 
and  compare  these  to  the  functional  needs  of  the  Marine  Squad.  The  team  evaluated  the 
different  technical,  logistical,  and  fiscal  considerations  using  systems  engineering 
principles  and  analysis. 

A  "Zwicky's  Morphological  Box'  was  used  as  a  technique  to  develop  possible 
system  alternatives.  This  approach  encourages  brainstorming  at  the  sub-system  level  and 
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the  subsequent  combination  of  the  brainstormed  ideas  in  untried  combinations  as  a  way 
to  produce  new  approaches  to  be  vetted  in  feasibility  screening  phase  of  the  SEDP. 

The  first  step  in  Zwicky’s  process  is  the  definition  of  system  elements.  These 
elements  correspond  to  the  functions  described  in  our  Value  Model  in  Figure  20.  These 
elements  were  defined  as: 

■  Receive/Transmit 

■  Communication  Processor 

■  Communication  Generator 

■  Convey  Information  to  User 

■  Power  Supply 

The  SE  team  then  combined  various  combinations  of  functions  to  establish 
alternatives.  Using  engineering  judgment,  the  SE  team  eliminated  the  impossible 
solutions  while  preserving  both  common  and  unusual  combinations  for  comparison  in 
feasibility  screening. 
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Receive  / 
Transmit  System 

Processor 

System 

Input  System 

Output  System 

Power  System 

FM  Radio 

Software  on  PDA 

Keyboard 

External  Earpiece  / 
mic,  headphones 

Rechargeable 
Lithium  Ion 

Cell  Phone 

Software  on  Laptop 

Pointer  /  Mouse 

Integrated  Screen 

Alkaline  -  non 
rechargeable 

Satellite  Phone 

Software  on 
Cellphone 

Voice  Recognition  • 
CODEC 

External  connection 
-  Heads  up  display 

Solar  rechargeable 
battery 

AM  Radio 

Software  on 
integrated 
communication 
device 

Touchpad 

Integrated  speaker  / 
mic 

Piezoelectric 
rechargeable  battery 

Laser 

Config  1 


Config  3 

Config  4 


All  configurations  must  Configurations  must  have 

enable  user  alternatives/  integrated  power  that 

selection  for  these  two  meets  minimum 

functions  endurance  criteria 


Figure  20:  Morphological  Box 
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4.  Feasibility  Screening 

The  goal  of  the  Systems  Engineering  design  process  is  to  come  up  with  a  single 
solution  that  will  best  meet  the  needs  of  the  Marine  Corps  Rifle  Squad  Leader.  Team 
Marine  executed  a  detailed  analysis  of  the  required  functionality  of  the  squad 
communication  system  based  on  utilizing  handheld  radio  unit(s).  In  addition,  scenarios 
were  drawn  up  discussing  how  the  system  will  be  used  in  a  real-time  operational 
environment.  The  SE  team  took  all  the  requirements  and  generated  a  list  of  material 
alternatives  /  solutions.  Often  the  alternatives  generated  may  not  be  technologically  or 
financially  viable.  These  solutions  were  put  through  a  feasibility  screening  process  to 
help  the  team  move  towards  indentifying  a  single  hand-held  radio  solution  that  will  best 
fulfill  the  effective  needs  statement  outlined  in  section  IIB3  above. 

Feasibility  screening  is  an  iterative  process  and  is  designed  to  give  Systems 
Engineers  a  way  to  methodically  eliminate  solutions  after  the  alternatives  generation 
brainstorming  phase  that  are  determined  to  be  clearly  infeasible.  In  most  cases, 
infeasibility  is  determined  when  applying  the  alternatives  against  a  list  of  system  and 
program  constraints.  These  constraints  may  be  performance-based,  such  as  the  radios 
need  to  be  able  to  send/receive  both  voice  and  data.  Oftentimes,  depending  on  the  stage 
of  the  program,  a  team  may  apply  financial  or  economic  constraints  on  the  alternatives,  in 
order  to  eliminate  systems  that  may  be  just  too  costly  to  acquire. 

The  nine  constraints  that  Team  Marine  identified  to  be  relevant  are  as  follows: 

1.  The  overall  system  weight  shall  be  lighter  when  compared  to  “status  quo” 
configuration 

2.  The  system  shall  be  capable  of  transmitting  and  receiving  Type  I  and  Type  11 
encrypted  messages  -  (2  channels  minimum) 

3.  The  system  shall  be  capable  of  supporting  world-wide  spectrum  supportability 
-  (must  support  a  variety  of  DoD  frequency  ranges) 

4.  The  system  shall  have  the  capability  to  support  enhanced  data  capability 
including  digital  data  and  streaming  video  -  (can  not  be  voice  only) 

5.  The  system  shall  have  the  capability  to  recharge  power  sources  during  mission 
operations  -  (charging  must  occur  while  in  operation) 
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6.  The  system  shall  be  capable  of  gracefully  entering  and  exiting  a  tactical  ad- 
hoc  network 

7.  The  system  shall  be  configurable  by  users  below  Squad  Leader 

8.  The  system  shall  operate  independent  of  commercial  telecommunication 
infrastructure 

9.  Range  for  both  Line-of-Sight  (LOS)  and  Non-Line-of-Sight  (NLOS)  shall  be 
at  least  3  km 

The  team  applied  the  Feasibility  Screening  Matrix  Table  3  below,  which  identifies 
specific  constraints  to  the  alternatives,  to  the  multiple  configurations  identified  in  Figure 
20.  This  activity  reduced  the  total  number  of  alternatives  identified  above  to  those 
practical  alternatives  that  need  further  investigation  and  analysis. 
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Table  3:  Feasibility  Screening  Matrix 


Operate  in  Military  Spectrum  Bands 


National  Security  Agency  (NSA) 
certified  or  certifiable 


Joint  Integrated  Test  Center  (JITC) 
certified  or  certifiable 


JTRS  SCA  2.2  compliant 


Requires  no  Satellite  Communication 
(SATCOM) 


Independent  of  commercial  telecom 
infrastructure 


Backwards  compatible  with  existing 
systems  until  FOC 


FM  Radio 
Configuration  I 


FM  Radio 
Configuration  2 


Cell  Phone 
Configuration  3 


Satellite  Phone 
Configuration  4 
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Configurations  identified  above  in  the  Morphological  Box  in  Figure  20  are  further 
subjected  to  operational  and  support  criteria.  A  brief  description  of  operational  and 
support  issues  that  each  alternative  was  subjected  to  follows. 

a.  Operational  Issues: 

To  best  suit  the  user  requirements,  the  following  operational  issues  must 

be  satisfied  by  each  alternative  in  consideration. 

■  The  system  shall  operate  in  accordance  to  standards  established  by 
Military  Spectrum  Specification,  MIL-STD  449D 

■  The  system  shall  meet  all  Operational  Environmental  specifications 
identified  in  MIL-STD-810F 

■  The  system  shall  be  certifiable  by  assessment  standards  as  established 
by  National  Security  Agency  (NS A) 

■  The  system  shall  be  certifiable  by  assessment  standards  as  established 
by  the  Joint  Interoperability  Test  Command  (JITC) 

■  The  system  shall  be  compliant  to  current  Software  Communication 
Architecture  (SCA)  standards 

■  The  system  shall  be  capable  of  sustaining  internal  power  requirements 
for  missions  lasting  no  less  than  8  hours 

■  The  system  shall  operate  independently  of  external  power 

b.  Support  Issues: 

To  best  suite  the  user  requirements  in  the  field,  the  following  Support 

issues  must  be  satisfied  by  each  alternative  in  consideration. 

■  The  system  shall  be  inter-operable  with  existing  and  legacy  waveforms 

■  The  system  shall  be  inter-operable  with  existing  fielded 
communications  systems 

■  The  system  shall  be  hardware  and  software  upgradeable  without  major 
re-engineering 

■  The  system  shall  maximize  use  of  existing  DoD,  and  USMC  logistical 
support  elements,  including  software  licensing,  batteries,  computers, 
etc. 
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■  The  system  shall  be  ergonomically  designed  to  fit  and  integrate  with 
existing  soldier  gear 

B  RECOMMENDED  ALTERNATIVES 


This  section  describes  the  four  (4)  selected  alternatives  based  on  the  completion 
of  the  Feasibility  Screening  process  above.  Configurations  #2  and  #4  in  Table  3  provided 
the  team  direction  to  look  at  specific  alternatives.  The  operational  and  support  issues 
were  used  to  further  refine  the  alternatives  prior  to  any  further  analysis.  Each  alternative 
below  has  five  physical  sub-systems  as  seen  in  Figure  21.  These  five  physical  sub¬ 
systems  are  required  to  support  the  functional  requirements  in  order  achieve  the  desired 
operational  capabilities  of  the  Squad  Leader.  The  five  primary  sub-systems  are: 


■  User  Input  System,  (microphone,  touch  pads,  keyboards,  etc) 

■  Output  System,  (speakers,  headsets,  LCD  display) 

■  Processor  System,  (Computer  Processing  Unit  (CPU)  provides  system 
configuration,  position  location  information,  executes  software  programs  and 
executes  encryption  functions  as  required) 

■  Receiver  /  Transmitter  (Rx/Tx)  System,  (Radio  Frequency  (RF)  spectrum 
management,  modulation  and  amplification  of  RF  signals) 

■  Power  System,  (batteries  or  other  electrical  power  supply) 


Receive 

Comms 


Receiver  /  Transmitter 
System 


Process 
Comms  ^ 


Input  Data 


A3 


Input  System 


Transmit 
Comms  a5 

Processor  System 

Output  Data 

A4 

Output  System 


Power 


A6 


Power  System 


Figure  21:  Key  Physical  Components  of  Alternatives 
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1.  Primitive  Alternative:  (Status  Quo) 


Human 

Processing 


Type  2 
(CUI  only) 


Self-contained  Crypto 


Telephone^eyboard 

(StandardVTexting) 


Spare  power 


Hand-set 

(Receive  &  Transmit) 

Type  1 
(Classified  up  to  Secret) 

Integrated  Screen 

Radio  Specific  Keyboard 
(Unique  Text  Layout) 


Spare  power 

Non-rechargeable  during  mission 
Hand  Held  GPS  Device 


Figure  22:  Primitive  Alternative 


The  primitive  alternative  is  the  currently  fielded  solution  being  employed  by 
Marine  squad  leaders  in  training  areas,  school  houses  and  in  ongoing  combat  operations. 
Figure  22  describes  the  alternative  by  the  specific  components.  This  alternative  is 
comprised  of  multiple  items  that  were  purchased  and  fielded  by  separate  Programs  of 
Record  managed  by  Marine  Corps  Systems  Command  (MCSC).  These  items  were  not 
bought  as  an  integrated  system  and  are  not  fundamentally  interoperable  or  meant  to  be 
employed  together.  However,  the  squad  leaders  have  learned  how  to  employ  these  items 
in  an  integrated  capable  system  to  meet  minimum  functionality  and  capability. 

Input  System 

The  input  devices  are  comprised  of  hand-sets  or  internal  microphones  for 
voice  input  communications.  The  operator  must  use  a  simple  switch  to 
select  which  radio  device  they  desire  to  communicate  on.  There  is  no  data 
capability  currently  associated  with  this  alternative.  External  and 
disconnected  from  the  radio(s)  is  a  handheld  GPS  unit  that  provides  the 
squad  leader  with  current  position  and  any  pre-programmed  routes  or  way- 
points  associated  with  anticipated  and  planned  mission  profiles.  The 
squad  leader  must  read  the  data  from  the  GPS  in  order  to  communicate 
this  information  across  the  voice  only  circuits  and  must  do  this  once  on  the 
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Type  1  AN/PRC  152  radio  and  again  on  the  Type  2  IISR  (AN/PRC-153) 
radio. 

Processor  System  /  CPU 

There  is  no  data  processing  capability  associated  with  this  alternative.  The 
squad  leader  must  process  all  voice  traffic  and  must  generate  their 
information  as  a  mental  image. 

Power  System 

There  are  three  non- interchangeable  types  of  batteries  associated  with  this 
alternative.  The  IISR  (AN/PRC- 153)  uses  commercially  procured  A-cell 
batteries.  The  AN/PRC- 152  uses  military  procured  chargeable  and  one 
time  use  BA-5590s  batteries.  The  GPS  unit  uses  an  internally 
rechargeable  battery  which  has  an  option  of  using  commercially  procured 
C-cell  batteries. 

Rx/Tx  System 

There  are  two  radios  associated  with  this  alternative  that  are  not 
interoperable  and  do  not  share  or  use  a  common  transmission  spectrum. 
The  IISR  (AN/PRC- 153)  is  a  line-of-site  radio  that  provides 
preprogrammed  channels  associated  with  Radio  Nets  for  team  and  leader 
voice  circuits.  The  IISR  (AN/PRC-153)  has  a  short  transmission  range  of 
less  than  3  kilometers  with  degraded  capability  in  heavy  vegetation  and 
urban  structures.  The  AN/PRC-152  has  a  longer  transmission  range  that 
extends  to  10  kilometers  but  is  also  line-of-site  dependent  and  also 
encounters  degraded  capability  when  employed  in  heavy  vegetation  and 
urban  structures. 

Output  System 

There  is  only  one  headset  or  handset  with  a  speaker  or  ear-piece  for  the 
operator  to  listen  with.  The  operator  listens  to  both  radios  simultaneously. 
Each  radio  has  a  small  LCD  display  which  also  provides  information  to 
the  user.  There  is  currently  no  visible  texting  or  video  capability  on  either 
radio. 


-59- 


2.  Current  Alternative: 


Figure  23:  Current  Alternative 

This  alternative  is  identical  to  the  Primitive  Alternative  with  the  following  exception; 
an  integrated,  ruggedized  laptop  that  has  an  embedded  military  GPS  receiver.  This 
enhancement  is  currently  being  fielded  and  employed  by  a  few  select  U.S.  Marine  squad 
leaders  in  training  areas,  and  school  houses.  The  Current  Alternative  (Figure  23)  is 
comprised  of  many  of  the  same  items  that  were  purchased  and  fielded  by  Marine  Corps 
Systems  Command  (MCSC)  for  the  Primitive  Alternative.  Again  these  items  were  not 
bought  as  an  integrated  system  and  are  not  fundamentally  interoperable;  however,  the 
squad  leaders  have  learned  to  employ  these  items  in  the  field  to  meet  operational  needs. 

Input  System 

The  input  devices  are  comprised  of  hand-sets  or  internal  microphones  for 
voice  input  communications,  and  a  ruggedized  laptop  to  input  and  receive 
data  communications.  Integrated  into  the  laptop  is  an  embedded  GPS  unit 
that  provides  the  squad  leader  with  current  position  and  any  pre¬ 
programmed  routes  or  way-points  associated  with  anticipated  and  planned 
mission  profiles. 
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Processor  System  /  CPU 

The  ruggedized  laptop  provides  minimal  computing  capability  to  convey 
and  display  unit  level  C2/SA.  The  laptop  is  configured  with  military  and 
commercial  software  offering  limited  data  capability  to  the  squad  leader. 

Power  System 

There  are  three  non- interchangeable  types  of  batteries  associated  with  this 
alternative.  The  IISR  (AN/PRC- 153)  uses  commercially  procured  A-cell 
batteries.  The  AN/PRC- 152  uses  military  procured  chargeable  and  one 
time  use  BA-5590s.  The  laptop  unit  uses  an  internally  rechargeable 
battery  with  option  of  using  externally  generated  DC  power. 

Rx/Tx  System 

There  are  two  radios  associated  with  this  alternative  that  are  not 
interoperable  and  do  not  share  or  use  a  common  transmission  spectrum. 
The  IISR  (AN/PRC- 153)  is  a  line-of-site  radio  that  provides 
preprogrammed  channels  associated  with  Radio  Nets  for  team  and  leader 
voice  circuits.  The  IISR  (AN/PRC-153)  has  a  short  transmission  range  of 
less  than  3  kilometers  with  degraded  capability  in  heavy  vegetation  and 
urban  structures.  The  AN/PRC-152  has  a  longer  transmission  range  that 
extends  to  10  kilometers  but  is  line-of-site  dependent  and  also  encounters 
degraded  capability  when  employed  in  heavy  vegetation  and  urban 
structures. 

Output  System 

There  is  a  cable  required  to  connect  the  laptop  to  the  AN/PRC- 152.  This 
cable  is  made  specifically  for  this  radio  and  is  proprietary  to  this 
employment  option. 
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3.  Advanced  Alternative: 


This  alternative  is  a  first  attempt  at  providing  the  squad  leader  with  a  fully 
integrated  system  comprised  of  wearable  and  hand-held  sub-systems.  This  design  is 
being  evaluated  by  PM  Soldier  for  the  Ground  Soldier  Ensemble  (GSE).  It  offers  user 
tailorable  allowing  for  each  squad  leader  or  unit  to  determine  best  mix  of  capability.  The 
Advanced  Alternative  (Figure  24)  is  currently  being  evaluated  by  the  Army  and  select 
Marine  Corps  units  for  consideration.  Previous  prototype  designs  of  this  alternative  have 
been  employed  by  soldiers  in  operations  in  Iraq  and  are  currently  being  employed  in  both 
Iraq  and  Afghanistan. 

Input  System 

The  input  devices  are  comprised  of  hand-sets  or  internal  microphones  for 
voice  input  communications,  and  user  specified  data  input  devices. 
Several  alternative  data  input  devices  are  being  evaluated  to  include 
“gameboy”  controllers,  touch-screens,  hand-held  mouse  assembly  units, 
and  wearable  keypads.  Integrated  into  the  system  is  an  embedded  GPS 
unit  that  provides  the  squad  leader  with  current  position  and  any  pre- 
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programmed  routes  or  way-points  associated  with  anticipated  and  planned 
mission  profiles. 

Processor  System  /  CPU 

The  wearable  computer  provides  advanced  computing  capability  to 
convey  and  display  unit  level  C2/SA.  It  is  configured  with  military  and 
commercial  software  offering  enhanced  data  capability  to  the  squad 
leader. 

Power  System 

There  are  two  non-interchangeable  types  of  batteries  associated  with  this 
alternative.  The  Rifleman  Radio  (RR)  uses  military  procured  chargeable 
and  one  time  use  BA-5590s.  The  wearable  backpack  system  uses  an 
internally  rechargeable  battery  with  option  of  using  externally  generated 
DC  power. 

Rx/Tx  System 

There  are  two  radios  associated  with  this  alternative  that  are  interoperable 
and  do  not  share  or  use  a  common  transmission  spectrum.  Due  to  the  two 
classification  levels,  the  RR  via  a  data-diode  injects  individual  Position 
Location  Information  (PLI)  into  the  fully  operable  data  processing  unit 
worn  by  the  squad  leader.  The  radios  are  line-of-site  radios  that  provide 
preprogrammed  channels  associated  with  Radio  Nets  for  team  and  leader 
voice  and  data  circuits.  They  are  line-of-site  dependent  and  are  effective 
for  ranges  of  10-15  kilometers  and  also  encounter  degraded  capability 
when  employed  in  heavy  vegetation  and  urban  structures.  The  radios 
provided  through  the  Joint  Tactical  Radio  System  (JTRS)  bring  enhanced 
capability  by  providing  meshing  and  ad-hoc  networking. 

Output  System 

The  cable  assembly  is  integrated  into  the  wearable  system  with  the  ability 
to  use  external  cables  for  user  specific  employment  options. 
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4.  Future  Alternative: 


Heads  up  display 


Voice  Recognition 
Microphon'e^^ 

Display  /  Touchpad 


Internal  Earpiece 


Type  2 
Type  1 


Integrated  Processing  and 
Encryption  Software 

Internal  GPS 
Power  Storage 


Piezoelectric 
(Power  Generation) 


Figure  25:  Future  Alternative 

This  alternative  is  only  a  concept  at  this  point  as  only  a  few  components  are 
commercially  available,  while  many  others  are  currently  under  Research  and 
Development  today.  The  Future  Alternative  (Figure  25)  represents  a  fully  integrated 
system,  with  a  complete  evaluation  of  human  factors. 

Input  System 

The  input  devices  should  be  tailorable  and  provide  user  input  associated 
with  “I-touch”  like  capability. 

Processor  System  /  CPU 

The  wearable  computer  should  provide  advanced  computing  capability  to 
convey  and  display  unit  level  C2/SA.  It  is  configured  with  military  and 
commercial  software  offering  enhanced  data  capability  to  the  squad 
leader. 
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Power  System 

The  power  supply  should  seek  alternative  power  generation  alternatives  - 
one  example  is  the  piezoelectric  powered  insoles  pictured  above. 

Rx/Tx  System 

The  radio  provided  through  the  Joint  Tactical  Radio  System  (JTRS)  or 
other  programs  must  provide  integrated,  multi-level  security  into  a  single 
device  with  enhanced  capability  by  providing  meshing  and  ad-hoc 
networking. 

Output  System 

The  output  system  must  be  compatible  with  night  vision  displays  or 
goggles.  This  design  should  seek  to  minimize  cables  and  use  wireless 
alternative  options  to  “tie”  the  devices  together  -  much  like  Bluetooth 
does  for  headsets  and  cell  phones. 

C  MODELING  AND  SIMULATION 

1.  Tools  and  Approach 

The  Squad  Communication  System  model  was  developed  using  Arena  10.0  student 
version.  Arena  is  a  modeling  and  simulation  tool  produced  by  Rockwell  Automation  to 
provide  the  user  with  alternative  and  interchangeable  templates  of  graphical  simulation 
modeling  and  analysis  modules  that  can  be  graphically  combined  to  mathematically 
model  and  simulate  systems  for  detailed  analysis  of  the  system.  (Kelton,  Sadowski, 
Sturrock,  2007).  The  model  represents  a  Marine  Corps  Squad  Leader’s  ability  to  receive, 
generate,  and  process  communication  messages.  The  model  measures  the  workload 
associated  within  a  typical  squad  employment  scenario  and  measures  the  ability  of  a  of 
the  squad  leader  to  communicate  with  higher  headquarters  and  the  squad  fire  teams.  The 
Squad  Communication  model  is  a  queuing  model  to  mimic  workload  capacity  of  a 
Marine  Corps  Squad  Leader. 

a.  Workload  Methodology 

The  workload  methodology  for  modeling  human  performance  is  based  on  the 
multiple  resource  theory  for  discrete  events  originally  developed  by  Wickens  (1984). 
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Wickens  described  work  load  as  total  demand  placed  on  human  as  he/she  performs  a  task 
(as  cited  by  Keller,  2002).  Workload  could  thus  be  described  as  the  total  demand  placed 
on  the  Squad  Leader  as  he/she  performs  a  task.  In  Multiple  Resource  Theory,  workload 
is  not  just  the  result  of  one  central  processing  resource  but  the  use  of  several  processing 
resources  or  workload  channels.  The  multiple  resources  are  described  as  visual,  auditory, 
cognitive  and  psychomotor.  Rating  scales  for  each  of  these  resources  were  developed  to 
describe  the  workload  required  to  do  generic  tasks  or  anchoring  statements.  The  rating 
scales  in  Figure  2  were  originally  developed  based  on  work  by  McCrasken  &  Aldrich 
(1984)  and  Bierbaum,  Sxabo  &  Aldrich  (1987).  However  the  rating  scales  updated  in 
2000  by  the  Army  Research  Laboratory  (Mitchell,  D.K.  2000)  and  used  in  the  task 
analysis  for  performing  the  system  communication  functions. 
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Table  4:  Simulation  Descriptors  and  Scale  Values 


Descriptors 

Scale 

Value 

Visually 

Visually  register  or  detect  (detect  occurrence  of  image) 

3.0 

Visually  inspect  or  check  (discrete  inspection  or  static  condition) 

3.0 

Visually  locate  or  align  (selective  orientation) 

4.0 

Visually  track  or  follow  (maintain  orientation) 

4.4 

Visually  discriminate  (detect  visual  differences) 

5.0 

Visually  read  (symbol) 

5.0 

Visually  scan  or  search  monitor  (continuous  or  serial  inspection,  multiple  conditions) 

6.0 

Auditory 

Detect  or  register  sound  (detect  occurrence  of  sound) 

1.0 

Orient  to  sound  (general  orientation  or  attention) 

2.0 

Orient  to  sound  (selective  orientation  or  attention) 

4.2 

Verify  auditory  feedback  (detect  occurrence  of  anticipated  sound) 

4.3 

Interpret  semantic  content  (speech)  simple  (1  to  2  words)  complex  sentences 

3.0 

Interpret  semantic  content  (speech)  complex  sentences 

6.0 

Discriminate  sound  characteristics  (detect  auditory  difference) 

6.6 

Interpret  sound  patterns  (pulse  rates,  etc) 

7.0 

Cognitive 

Automatic  (simple  association) 

1.0 

Alternative  selection 

1.2 

Sign  or  Signal  recognition 

3.7 

Evaluation  or  judgment  (consider  single  aspect) 

4.6 

Rehearsal 

5.0 

Encoding  or  decoding,  recall 

5.3 

Evaluation  or  judgment 

6.8 

Estimation,  calculation,  conversion 

6.8 

Psychomotor 

Speech 

Speech  simple  (1  to  2  words) 

2.0 

Complex  (sentence) 

4.0 

Motor 

Discrete  actuation  (button,  toggle,  trigger) 

2.2 

Continuous  adjustive  (flight  control,  sensor  control) 

2.6 

Manipulative 

4.6 

Discrete  adjustment  (rotary,  vertical  thumb  wheel,  lever  position) 

5.5 

Symbolic  production  (writing) 

6.5 

Serial  discrete  manipulation  (keyboard  entries) 

7.0 

b.  Communication  Messages  Task  Analysis 

The  functions  were  taken  directly  from  the  Functional  Analysis  and  further 
decomposed  into  specific  human  tasks  for  operating  the  four  alternatives  defined  earlier 
in  the  system  engineering  methodology.  The  generic  tasks  associated  with  each  function 
were  further  defined  from  the  alternatives  and  given  a  scale  value.  This  task  analysis  and 
assignment  of  value  is  limited  in  scope  for  this  project  and  has  evolved  as  a  mental 
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exercise  in  performing  the  tasks.  Further  analysis  should  include  alternative  mock-ups, 
testing  with  actual  users,  and  completed  surveys  to  better  understand  the  intricacies  of  the 
alternatives.  This  conceptual  analysis  will  help  to  determine  qualitative  differences  in 
levels  of  workload  required  to  send  and  receive  communication  messages.  The  limited 
scope  task  analysis  is  referenced  below: 

Receive  Communication  Information: 

1 .  No  Human  tasks  for  any  alternative 
Process  Automated  GPS:* 

1.  Toggle  GPS  buttons  Read  GPS  (Voice  only) 

2.  Read  GPS  data  (Voice  only) 

3.  Evaluate  GPS  data  (Voice  only) 

Note:  *  Data  -  No  Human  tasks  for  any  alternative 
Process  Communication  Information:  -  Send 

1 .  Physically  change  radios  (if  two  radio  solutions  are  used) 

2.  Gather  information  to  be  sent:  Recall  voice  information  if  transferred 
from  radio  or  retrieve  stored  data 

3.  Verbalize  information  into  hand  microphone  -or-  voice  recognition 
device  -or-  input  via  a  keyboard 

Process  Communication  Information:  -  Receive: 

1 .  No  Human  tasks  for  any  alternative 
Transmit  Communication  Information:  -  Send 

1.  Toggle  send  key  -or-  push  send  key  -or-  verbally  send  via  voice 
recognition  device. 

Convey  Information  to  User 

1.  Physically  move  handset  to  ear  -or-  open  screen  -or-  move  screen  into 
view. 

2.  Listen  to  message  or  read  message 

3.  Write  down  required  information  (voice  only) 

4.  Evaluate  information 

c.  Simulation  Model  Part  Descriptions 
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Overall  Simulation  Process:  The  Arena  model  will  model  the  communications 
process  using  discrete  events,  taking  a  message  through  the  entire  communications 
process  over  time  steps  and  measuring  Squad  Leader  workload.  The  model  will  process 
receiving  or  sending  message  as  a  delay,  release,  and  by  assigning  a  workload  attribute 
process.  These  parameters  will  be  established  based  on  the  individual  solutions  in  the 
system  alternatives. 

Entity  Generators:  Each  message  required  for  the  simulation  for  both  generated 
and  received  messages  is  controlled  by  a  entity  generator.  Each  message  generator 
introduces  a  communication  message  (entity)  to  the  squad  leader  in  order  to  process  a 
receive  message  or  generate  an  outgoing  message.  This  entity  will  have  attributes  that 
describe  the  message  and  be  used  in  the  processing  sub-models  within  the  overall  model 

Entities  Attributes:  An  attribute  is  a  common  characteristic  of  all  the  entities, 
but  specific  values  can  differ  from  the  other  entities.  (Kelton,  Sadowski  &  Sturrock, 
2007).  Each  message  has  two  levels  of  attributes  1)  Message  Descriptions  and  2) 
Workload  Descriptions  assigned  and  used  in  the  simulation. 

1.  Message  Descriptions  Attributes: 

Data  Message:  -  if  1,  then  this  message  is  a  data  only  message;  if  0,  this  message 
is  a  voice  only  message 

Generate  Message:  -  if  1,  then  this  is  a  message  that  needs  to  be  generated;  if  0, 
this  is  received  message 

Need  GPS:  -  if  1,  then  this  generated  message  needs  GPS  coordinates;  if  0,  this 
message  does  not  need  GPS  coordinates. 

Lines  in  Message:  -  the  number  of  lines  in  the  message  to  convey  sufficient 
information. 

Renege  Time:  -  the  max  time  the  message  is  still  relevant  to  the  squad  leader. 
Once  the  renege  time  is  reached,  the  model  will  pull  the  entity  from  the  queue  and 
free  up  the  workload  resource. 

2.  Workload  Descriptions  Attributes: 
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Visual  Auditory,  Cognitive,  and  Psychomotor  Workload  -  Assigned  a  rating  of  1 
-  7  for  each  functional  task  to  the  system  global  variable  as  it  passes  through  each 
of  the  alternatives.  Scale  values  and  descriptors  for  each  of  the  resources  are  in 
below. 

Total  Workload  -  Total  workload  is  sum  of  the  resources  for  that  specific 
functional  task. 

Global  Variables:  Global  variables  are  information  that  reflects  a  characteristic  of 
the  system  regardless  of  the  types  or  quantity  of  entities  in  the  simulation  (Kelton, 
Sadowski  &  Sturrock,  2007).  Variables  are  used  in  the  simulation  to  track  the  workloads 
within  the  system.  The  workload  description  attributes  described  in  the  entity  attributes 
work  together  to  ensure  the  system  properly  disposes  workload  after  the  entity  is 
processed.  Global  variables  include  total  workload,  visual  workload,  auditory  workload, 
cognitive  workload,  psychomotor  workload,  and  time  in  the  system. 

Queue:  A  queue  is  used  to  model  the  squad  leader’s  ability  to  seize  a  workload 
resource  as  described  by  the  entity  workload  description  attributes.  The  queue  provides 
the  gate  for  the  message  to  be  sent  or  received  without  over  taxing  the  squad  leader 
ability  to  process  that  message  (send  or  receive).  The  Communication  Processing  Queue 
will  attempt  to  process  Communication  Messages  (Entities)  until  it  meets  a  max  threshold 
of  total  workload,  visual  workload,  auditory  workload,  cognitive  workload,  or 
psychomotor  workload. 

Resource:  Once  an  entity  reaches  the  queue,  a  resource  must  be  pulled  in  order  to 
process  the  message.  The  resource  for  the  simulation  is  the  max  total  workloads,  max 
visual  workload,  max  auditory  workload,  max  cognitive  workload,  or  max  psychomotor 
workload.  The  lower  the  required  resource,  the  more  efficient  the  system  alternative 
performed. 
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Table  5:  Primitive  Alternative  Recorded  Parameters 


Primitive 

Human  Process  Time  (per 
line  in  message  or  per  GPS 
entry)(sec) 

[Triangular  Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive  Communication 

Information 

Voice 

0 

0 

0 

0 

0 

0 

Process  Automated  GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Process  Commo  Info  Send 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

4.6 

13.9 

Transmit  Commo  Info  Send 

Voice 

0 

0 

0 

0 

2.2 

2.2 

Process  Commo  Info  Receive 

Voice 

(8,10,12) 

0 


0 

0 

0 

6.5 

6.5 

Convey  Information  to  User 

Voice 

0 

6 

5.3 

0 

2.2 

13.5 
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Table  6  Current  Alternative  Recorded  Parameters 


Current 

Human  Process  Time 
(per  line  in  message  or 
per  GPS  entry)(sec) 
[Triangular  Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive  Communication  Information 

Voice 

0 

0 

0 

0 

0 

0 

Data 

0 

0 

0 

0 

0 

0 

Process  Automated  GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Data 

(3,5,8) 

0 

0 

0 

0 

0 

0 

Process  Commo  Info  Send 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

4.6 

13.9 

Data 

(15,25,35) 

0 

0 

1 

0 

7 

8 

Transmit  Commo  Info  Send 

Voice 

0 

0 

0 

0 

2.2 

2.2 

Data 

0 

0 

0 

0 

2.2 

2.2 

Process  Commo  Info  Receive 

Voice 

(8,10,12) 

0 

0 

0 

0 

6.5 

6.5 

Data 

(1,2,3) 

0 

0 

0 

0 

0 

0 

Convey  Information  to  User 

Voice 

0 

6 

5.3 

0 

0 

11.3 

Data 

5 

0 

4.6 

0 

4.6 

14.2 
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Table  7:  Advanced  Alternative  Recorded  Parameters 


Advanced 

Human  Process  Time 
(per  line  in  message  or 
per  GPS  entry)(sec) 
[Triangular  Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Receive  Communication  Information 

Voice 

0 

0 

0 

0 

0 

0 

Data 

0 

0 

0 

0 

0 

0 

Process  Automated  GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Data 

(3,5,8) 

0 

0 

0 

0 

0 

0 

Process  Commo  Info  Send 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

0 

9.3 

Data 

(20,30,40) 

3 

0 

1 

0 

2.2 

6.2 

Transmit  Commo  Info  Send 

Voice 

0 

0 

0 

0 

2.2 

2.2 

Data 

0 

0 

0 

0 

2.2 

2.2 

Process  Commo  Info  Receive 

Voice 

(8,10,12) 

0 

0 

0 

0 

6.5 

6.5 

Data 

(1,2,3) 

0 

0 

0 

0 

0 

0 

Convey  Information  to  User 

Voice 

0 

6 

5.3 

0 

0 

11.3 

Data 

5 

0 

1 

0 

2.2 

8.2 
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Table  8:  Future  Alternative  Recorded  Parameters 


Future 

Human  Process  Time 
(per  line  in  message 
or  per  GPS 
entry)(sec) 
[Triangular 
Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive  Communication  Information 

Voice 

0 

0 

0 

0 

0 

0 

Data 

0 

0 

0 

0 

0 

0 

Process  Automated  GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Data 

(3,5,8) 

0 

0 

0 

0 

0 

0 

Process  Commo  Info  Send 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

0 

9.3 

Data 

(10,15,18) 

1 

0 

1.2 

4 

0 

6.2 

Transmit  Commo  Info  Send 

Voice 

0 

0 

0 

0 

2.2 

2.2 

Data 

0 

0 

0 

2 

0 

2 

Process  Commo  Info  Receive 

Voice 

(8,10,12) 

0 

0 

0 

0 

6.5 

6.5 

Data 

(1,2,3) 

0 

0 

0 

0 

0 

0 

Convey  Information  to  User 

Voice 

0 

6 

5.3 

0 

0 

11.3 

Data 

5 

0 

1 

0 

0 

6 
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d.  System  Evaluation  Simulations 

As  discussed  previously,  the  purpose  of  the  simulation  was  to  measure  workload  on 
the  Squad  Leader  during  an  operational  scenario  using  the  various  alternatives.  The 
simulation  will  compare  the  number  of  messages  processed  to  the  total  messages  sent  or 
received  through  a  given  scenario  and  the  amount  of  workload  capacity  required.  The 
model  will  provide  the  following  inputs  in  to  the  analysis  of  alternatives  functions: 


Table  9:  Analysis  of  Alternative  Function  Simulation  Output 


A2  Process  Communications  Information 

All  Process  Incoming  Communication  Messages 

%  Processed  Incoming  Messages 

All  Process  Outgoing  Communication  Messages 

%  Processed  Outgoing  Messages 

N5  Ensure  Usability  &  Human  Factors 

N55:  Ability  &  Complexity  to  Consume  Analog  &  Digital  Data 

Max  Total  Workload 

e.  Model  Input/  Output 

There  are  three  primary  modules  requiring  inputs  in  order  to  define  the 
system  alternatives  and  the  scenario.  The  first  inputs  are  the  scenario  message 
generators.  The  message  generators  were  held  constant  for  all  simulation  of  the 
alternatives.  This  ensured  the  simulation  consistently  sent  the  same  number  of 
messages  in  relatively  same  amount  of  time.  The  second  inputs  were  the  attributes 
of  these  messages.  The  messages  varied  slightly  depending  on  the  capability  of  the 
alternative  to  process  data  and  voice  messages.  For  all  alternatives,  except  for  the 
primitive  alternative,  there  was  a  mixture  of  voice  and  data  messages.  For  the 
primitive  alternative,  there  were  no  data  messages  generated  due  to  the  lack  of  data 
capability.  The  input  values  for  the  scenarios  generators  and  message  attributes  are 

located  in  Table  10,  Table  11,  and 
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Table  12.  As  the  messages  are  being  processed  by  the  system,  multiple  variables 
and  attributes  were  assigned  to  define  the  workload  required  to  process  a  message.  The 
workload  attributes  and  variables  are  the  third  and  final  inputs  to  the  simulation.  These 
inputs  varied  with  the  workloads  required  to  perform  the  human  tasks  of  processing 
communication  messages  for  the  system  alternatives.  These  variables  and  attributes  are 
used  in  the  queuing  process  of  the  model.  The  output  of  the  simulation  helped  define 
ranking  of  the  alternatives  and  the  ability  of  the  squad  leader  to  process  those  messages. 
The  processing  attributes  are  defined  in  Table  5,  Table  6,  Table  7,  and  Table  8. 

Input  Values: 

1.  Messages  sent  and  received  by  the  squad  leader  include  (Table  12,  13,  14) 

a.  Number  of  lines  of  communications  in  each  message 

b.  Start  time  and  frequency  the  message  is  sent  or  received 

c.  Number  of  that  specific  type  of  message  is  sent  or  received. 

d.  Max  number  of  that  specific  type  of  message  is  sent  or  received  during 
the  scenario 

e.  The  estimated  max  time  the  message  becomes  irrelevant  to  the  squad 
leader  and  is  used  as  reneging  time  within  the  model. 

2.  Workload  for  each  Functional  Task  (Table  7,  8,  9,  10) 

a.  Human  Process  Time  per  line  of  the  message  or  per  GPS  entry  into  the 
message. 

b.  Workload  for  each  resource  and  total  workload  for  each  functional  task. 

Workload  will  be  measured  in  workload  units. 

Output  Values: 

1.  #  of  communication  messages  processed 

2.  #  of  communication  messages  reneged 

3.  Average  time  to  process  messages 

f.  Model  Descriptiou 
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The  model  has  a  main  view  that  consists  of  the  message  generators,  the  message 
attribute  assignment  module,  the  system  functional  processing  sub-model  and  the 
disposal  module.  The  system  functional  processing  model  consists  of  data  message 
processing  sub-model,  voice  message  process  sub-model,  the  model  queuing  sub-module, 
and  a  reneging  sub-module.  The  process  data  message  and  process  voice  message  sub¬ 
models  contain  the  same  functions  as  described  by  the  system  functional  architecture,  but 
varies  with  workloads  of  processing  voice  or  data  messages. 

2.  Situation 

The  patrol  is  operating  out  of  a  company  FOB  in  a  third-world  urban  city.  The 
FOB  is  well  situated  but  has  several  insurgents  and  unfriendly  personnel  in  the  vicinity. 
The  patrol  is  assessing  a  street  corridor  to  determine  level  of  hostile  activity  and  threat 
associated  with  occupying  forces.  The  patrol  has  complete  conductivity  with  appropriate 
units  as  outlined  in  the  operational  architecture.  This  includes  communications  to  the  fire 
teams  in  the  squad  for  order  execution. 

The  scenario  will  only  focus  on  the  squad  leader’s  ability  to  process 
communication  in  a  patrol  with  3  fire  teams. 


Patrol  Scenario  taken  from  the  Operational  Activity  Model  (OV-5)  of  the  Marine 
Expeditionary  Rifle  Squad  (MERS)  Architecture.  (MERS  Architecture  Final  Practicum 
Project  Report,  June  2008).  The  scenario  simulates  a  MERS  Combat  Operation  and 
begins  after  completion  of  the  Plan  Patrol  activity  during  the  Conduct  Patrol  activity. 


The  Execute  Route  command  has  been  given  and  the  maneuver  squad  is  moving  along 


designated  route  based  on  the  predefined  lat/long  coordinates. 


Consolidate 
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Figure  26:  Simulated  Scenario  Model 

Fire  Teams  will  report  position  location  information  and  situation  updates 
throughout  the  mission.  The  patrol  will  come  in  contact  with  the  enemy  along  the  route. 
The  enemy  is  a  small  insurgent  unit  intent  on  disrupting  the  patrol  movement  along  the 
route.  Upon  contact,  the  patrol  will  return  fire  and  call  in  artillery  fire  from  the  supporting 
artillery  battery  located  in  a  nearby  forward  operating  base.  Upon  suppression  of  the 
enemy  unit  with  direct  and  indirect  fire,  the  patrol  will  assault  the  enemy  position.  When 
the  enemy  unit  is  destroyed,  the  patrol  will  consolidate  and  request  causality  evacuations. 
Assumptions: 

•  No  voice  or  data  message  confirmations  will  be  modeled  (ie.  “Roger”,  “WILCO”, 
etc) 

•  Voice  or  data  only  messages.  Hybrid  messages  are  not  modeled. 

a.  Phase  1 

Conduct  Patrol  -  The  patrol  will  move  along  designated  routes  outlined  in  the  pre¬ 
determined  plan.  The  Squad  Leader  will  continually  communicate  current  position  and 
location  to  the  platoon  leader  and  synchronize  command  and  control  of  fire  teams  during 
movement.  Table  10  defines  the  inputs  to  the  simulation  for  phase  1. 

b.  Phase  2 

Engage  Enemy  -  The  patrol  taking  small  arms  fire  from  a  group  of  insurgents  in  urban 
terrain.  The  squad  employs  personal  weapons  for  effective  squad  protection  then  requests 
Fire  Support  to  suppress  the  enemy.  Once  the  enemy  is  suppressed,  the  patrol  assaults 
the  enemy  position  to  destroy  remaining  combatants.  Table  11  defines  the  inputs  to  the 
simulation  for  phase  2. 

c.  Phase  3 

Consolidate  Position  -  The  patrol  establishes  a  secure  boundary  to  repel  a  counter 
attack.  One  team  has  a  casualty  and  requests  a  MEDEVAC  for  a  wounded  squad 
member.  Table  12  the  inputs  to  the  simulation  for  phase  3. 
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Table  10:  Phase  1  Simulation  Events 


From 

To 

Message 

Type 

Lines  in 
Message 

start 

Time 

(min) 

Frequency 

#of 

Entities 

Max  # 

Renege 

Time 

(sec) 

FT 

SQD  LDR 

FT  Geographic  Position 

1 

1 

30 

TRIA(18,20,22) 

1 

3 

180 

SQD  LDR 

HQ 

SQD  Geographic  Position  / 

Friendly  Location 

II 

4 

35 

TRIA(20,30,40) 

1 

3 

1200 

FT 

SQD  LDR 

FT  Situation  Update_Patrol 

1 

2 

60 

TRIA(15,20,25) 

1 

3 

420 

SQD  LDR 

HQ 

SQD  Situation  Update_Patrol 

II 

2 

65 

TRIA(20,30,40) 

1 

3 

1200 

SQD  LDR 

FT 

SQD  Tactical  Connnnands  _Patrol 
(voice  only) 

1 

1 

0 

TRIA(18,20,22) 

1 

5 

60 
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Table  11:  Phase  2  Simulation  Events 


From 

To 

Message 

Type 

Lines  in 
Message 

Frequency 

#of 

Entities 

Max  # 

Renege 

Time 

(sec) 

FT 

SQD  LDR 

FT  Enemy  Location  Report 

1 

3 

120 

Once 

1 

1 

180 

SQD  LDR 

FT 

SQD  Terminal  Weapons 
Guidance_Engage 

1 

3 

121 

Once 

1 

1 

180 

SQD  LDR 

HQ 

SQD  Enemy  Locations 

II 

2 

123 

Once 

1 

1 

1200 

SQD  LDR 

HQ 

SQD  Situation  Upclate_Engage 

II 

2 

130 

TRIA(8,10,12) 

1 

4 

1200 

FT 

SQD  LDR 

FT  Call  for  Fire 

II 

5 

144 

Once 

1 

1 

420 

SQD 

HQ 

SQD  Call  for  Fire 

1 

5 

150 

Once 

1 

1 

HQ 

SQD 

Fire  Notification 

1 

1 

160 

Once 

1 

1 

60 

SQD 

FT 

SQD  Fire  Notification 

II 

1 

166 

Once 

1 

1 

60 

SQD  LDR 

FT 

SQD  Tactical  Commancls_Assault 
(voice  only) 

1 

1 

180 

Once 

1 

1 

60 
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Table  12:  Phase  3  Simulation  Events 


From 

To 

Message 

Type 

Lines  in 
Message 

Frequency 

#  of 

Entities 

Max  # 

Renege 

Time 

(min) 

SQD  LDR 

FT 

SQD  Tactical  Connnnancls_Secure 
(voice  only) 

1 

1 

200 

TRIA(4,5,10) 

1 

4 

60 

SQD  LDR 

FT 

SQD  Ternninal  Weapons 
Guiclance_Secure 

1 

3 

220 

Once 

1 

1 

60 

FT 

SQD  LDR 

FT  MEDEVAC  Request 

1 

3 

230 

Once 

1 

1 

180 

SQD  LDR 

HQ 

SQD  MEDEVAC  Request 

II 

3 

232 

Once 

1 

1 

180 

FT 

SQD  LDR 

FT_Causality  Report 

1 

4 

240 

Once 

1 

1 

420 

SQD  LDR 

HQ 

SQD  Mennbers  Health 

II 

4 

250 

Once 

1 

1 

1200 
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3.  Results 

Based  on  the  described  simulation  inputs,  the  results  are  shown  in  Table  13.  The 
Current,  Advanced,  and  Future  processed  the  same  percentages  of  incoming  (received) 
and  outgoing  (generated)  messages  with  45%  and  30%  respectively.  Although  they  were 
able  to  process  the  same  percentages  of  messages,  the  Future  was  the  only  alternative 
able  to  perform  this  without  violating  the  workload  threshold  of  8.0  workload  units  as 
defined  by  Multiple  Resource  Theory  by  Wickens  (1984).  The  Advanced  followed  just 
short  of  the  threshold  value  with  8.5  workload  units.  The  Current  and  Primitive  required 
81%  and  150%  more  workload  capacity  of  the  squad  leader  to  stay  within  the  range  of 
the  threshold  workload  value.  In  addition  a  high  max  total  workload,  the  Primitive 
alternative  could  not  process  outgoing  (generated)  messages  as  efficiently  as  the  other 
three  alternatives  with  only  19%  of  processed  outgoing  messages  processed. 


Table  13:  Simulation  Results 


Primitive 

Current 

Advanced 

Future 

%  Processed 

Incoming 

Messages 

10/22  = 

45% 

10/22  = 

45% 

10/22  = 

45% 

10/22  = 

45% 

%  Processed 

Outgoing 

Messages 

10/52  = 

19% 

16/52  = 

30% 

16/52  = 

30% 

16/52  = 

30% 

Max  Total 

Workload 

20.0 

14.5 

8.5 

6.5 

4.  Model  Limitations  and  Sensitivity 

As  with  most  models  and  simulations,  accurate  input  data  must  be  verify  and 
validated  with  the  results.  Because  this  was  a  qualitative  assessment  of  the  different 
alternatives  using  a  specific  workload  theory,  not  all  results  are  sufficient  to  predict  actual 
performance  but  provide  a  benchmark  for  comparison.  The  workload  values  have  a 
particular  sensitivity  to  the  outcome  of  the  simulation.  Actual  testing  should  be 
conducted  on  prototype  devices  with  a  sample  size  of  actual  users  that  can  normalize  the 
workload  values  of  the  different  alternatives.  This  would  lead  to  statistical  variations  in 
the  workload  values  rather  than  using  discrete  values  bound  by  anchor  statements  from 
previous  human  factor  studies.  Although  the  model  has  these  limitations  as  described 

above,  the  level  of  confidence  in  the  qualitative  assessment  of  the  alternatives  is  strong 
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enough  to  be  used  in  the  decision  matrix  and  be  evaluated  for  the  sensitivity  of  the  overall 
outcome  of  the  recommended  alternative. 

D  ALTERNATIVES  SCORING 

After  the  modeling  and  simulation  analysis  was  completed,  the  team  used  the 
remaining  weighting  factors  as  criteria  to  further  analyze  the  four  recommended 
alternatives.  This  section  describes  the  analysis  completed  for  the  system  weight,  power 
duration,  usability  and  reliability. 

1.  Physical  Weight  Analysis 

The  physical  weight  of  the  communications  system  is  extremely  important  to  the 
person  who  must  carry  the  system  into  battle.  War-fighters  have  been  known  to  saw  off 
the  end  of  their  toothbrushes  to  reduce  the  weight  so  that  they  can  carry  more  food  and 
ammunition.  Therefore  the  users  hold  physical  weight  to  be  of  significant  interest.  The 
less  weight  the  better.  For  that  reason  physical  weight  has  a  significant  weighting  factor. 
To  determine  the  raw  weight  score  for  the  four  alternatives  the  components  weights  were 
added  to  determine  an  overall  system  weight.  The  total  system  weight  for  each 
alternative  is  displayed  in  Table  14  below.  The  actual  components  of  each  alternative  are 
shown  in  Figure  22  through  Figure  25  and  are  listed  in  Table  17  and  Table  18.  When  the 
four  alternatives  are  compared  it  should  be  noted  that  the  future  system  combined  weight 
is  much  less  than  the  other  systems.  This  is  because  the  future  system  takes  advantage  of 
internal  circuitry  and  weight  reducing  materials.  The  other  three  alternatives  are  very 
close  in  weight.  When  scoring  the  four  alternatives  the  future  system  is  ranked  first. 


Table  14:  Physical  Weight  comparison 


Primitive 

Current 

Advanced 

Future 

Total  Physical 
Weight 

13  pounds 

13.8  pounds 

12.6  pounds 

5.7  pounds 

2.  Power  Duration  (Battery  Life)  Analysis 

A  close  second  in  importance  to  the  user  is  the  battery  life  of  the  system.  The 
system  must  supply  sufficient  power  to  the  system  to  permit  effective  communication  or 
the  system  is  of  little  use  to  the  war-fighter.  Work  continues  to  provide  a  rechargeable 
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power  source  in  the  field,  however,  at  this  time  no  reliable  rechargeable  source  is  on  the 
horizon.  Therefore  internal  and  replaceable  batteries  will  be  used  for  the  foreseeable 
future.  As  can  be  seen  from  Table  15  below,  battery  life  technology  produces  similar  life 
for  all  four  alternatives;  however,  the  future  system  has  a  power  regeneration  component 
and  thus  can  extend  the  total  duration  time  for  a  much  longer  period.  To  determine  the 
battery  life  the  shortest  battery  life  in  the  system  was  used  as  the  defining  raw  score  for 
the  system.  The  future  system  again  is  ranked  first. 


Table  15:  Power  Duration  comparison 


Primitive 

Current 

Advanced 

Future 

Power  Duration 
=  Battery  life 

6.5  hours 

8  hours 

8.5  hours 

>10  hours 

3.  Usability  Analysis 

The  usability  analysis  was  an  overall  look  at  each  system  as  a  whole  using  a 
Likert  Scale  (1-7)  where  seven  represents  the  system  that  is  easiest  to  use.  Eleven 
participants  conducted  a  paper  evaluation  on  the  overall  ease  of  use  for  each  of  the  four 
alternatives.  Statistical  analysis  was  performed  on  the  surveys  and  the  median  scores  are 
presented  in  Table  16. 


Table  16:  Ease  of  Use  Comparison 


Primitive 

Current 

Advanced 

Future 

Likert  Score 

4.5 

5.0 

6.0 

7.0 

4.  Reliability  Analysis 

Reliability  was  selected  as  a  quantitative  measure  to  aid  the  team  in  decision 
making.  The  primary  physical  elements  of  the  communications  system  for  each 
alternative  were  defined  and  evaluated.  Table  17  below  shows  each  of  the  key 
components  and  their  corresponding  Reliability  data.  Data  was  captured  via 
manufacturer  printed  material  as  well  as  market  research  on  commercially  available 
components.  Though  specific  products  or  manufacturers  declare  unique  Mean  Time 
Between  Failure  (MTBF)  values,  there  is  enough  testing  and  documented  literature  to 

provide  essential  trends  for  various  products. 
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Each  component’s  Reliability  value  (R- value)  was  calculated  by  using  the 
reliability  equations  from  Sage  &  Armstrong  [4]  below. 

A=  M  ^J 

Where  jJ  is  the  MTBF  and 
R(t)  =  e 
Where  t  is  time 


The  minimum  mission  duration  for  the  squad  is  approximately  eight  hours,  and 
thus,  eight  was  the  value  used  for  t  in  all  calculations. 


The  R- value  equations  for  systems  in  serial  and  parallel  configurations,  (Figure  27 
and  Figure  28  respectively)  are  given  below: 


Input 


Output 


R 


total 


Rc 


Figure  27 :  Serial  Reliability  Equation 


Input 


Component 

A 


Component 

B 


Component 

C 


Output 


R,„,3,  =  1-(1-RJ*(1-Rb)*(1-Rc) 

Figure  28:  Parallel  Reliability  Equation 

The  exact  configuration  of  each  alternative  and  the  components  used  in  each 
alternative  defined  the  equations  used  which  are  also  annotated  in  Table  17  below. 


-85- 


Table  17:  Reliability  Values  -  Components  and  Alternatives 


MISSION  DURATION 

8.00 

hours 

Component 

MTBF 

=  mu 

lambda  = 
1/mu 

R-value  =  e'' 
(-lambda*t) 

A 

BATTERY  POWER 

250 

0.004000 

0.96851 

B 

HEADSET/ MIC 

3900 

0.000256 

0.99795 

C 

LCD  DISPLAY /SCREEN 

50000 

0.000020 

0.99984 

D 

RADIO  (Rx/Tx) 

10000 

0.000100 

0.99920 

E 

KEYPADS 

20000 

0.000050 

0.99960 

F 

COMMS  PROCESSOR 

10000 

0.000100 

0.99920 

G 

GPS  UNIT 

15000 

0.000067 

0.99947 

H 

HUMAN 

2000 

0.000500 

0.99601 

1 

PIEZO  ELECTRIC  POWER 

20000 

0.000050 

0.99960 

Alternative  Components 

Alternative 

R-Value 

A*D*B*H 

PRIMITIVE 

0.96189 

CURRENT 


0.96387 


A*(1-(1-B)(1-E))*D*F*G*(1-(1-B)(1- 

C))*H 


ADVANCED 


0.96258 


l*(l-(l-B)(l-E))  *D*F*G*(1-(1-B)(1-C))*H  FUTURE 


0.99481 


Each  alternative  has  a  total  system  R-value  based  on  the  physical  components 
used  and  their  respective  individual  R-values,  as  well  as  the  component  layout,  (serial, 
parallel  or  combinations  of  both).  The  total  R-values  for  each  alternative  is  provided  in 
Table  17  above.  It  can  be  shown  quantitatively  that  the  Future  Alternative  has  the  highest 
total  system  reliability  value  (99.48%  of  an  8  hour  mission). 
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E  COST  ANALYSIS 


The  methods  described  above  develop  a  single  utility  value  or  score  for  each 
alternative  that  could  be  used  to  select  the  recommended  alternative.  However,  doing  so 
would  be  premature.  Total  utility  is  not  the  only  important  criterion  left  with  which  to 
judge  the  possible  solutions.  Each  of  the  four  alternatives  is  deemed  feasible.  These 
alternatives  are  further  analyzed  to  determine  level  of  added  capability  provided  and  at 
what  cost  in  section  IVD.  The  objective  is  to  assess  the  Return  on  Investment. 

1.  Acquisition  Costs 

The  cost  of  each  alternative  must  be  addressed.  The  cost  is  examined  relative  to 
Acquisition  and  Operations  and  Support  (O&S)  Cost.  Each  alternative  may  have 
significantly  different  costs  which  affect  the  decision  as  to  which  alternative  should  be 
pursued.  It  is  not  this  team’s  job  to  make  the  final  decision  but  to  provide  the 
stakeholders  with  a  recommendation  and  the  information  they  need  to  make  intelligent 
decisions. 

Each  alternative  is  composed  of  a  set  of  components.  Some  components  are  used 
in  more  than  one  alternative,  but  each  alternative  is  unique.  Most  of  the  components  are 
initially  purchased  from  existing  programs  of  record. 

Spreadsheets  were  used  to  capture  component  data  and  to  analyze  both 
mathematically  and  graphically  the  relationships  and  relative  costs  between  alternatives. 
In  order  to  generate  a  cost  estimate  for  a  single  alternative,  the  cumulative  costs  of  the 
components  were  determined  or  estimated  based  on  cost  analysis 
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Table  18:  System  Components  for  Each  Alternative 


Primitive  Alt 

Current  Alt 

Advanced  Alt 

Future  Alt 

PRC  152 
(ECO  pg  26) 

PRC  152 
(ECO  pg  26) 

PRC  154 
(EDM)  Incr  1 
(RR  CPD  pg  4) 

PRC  154 
(EDM)  Incr  2 
(RR  CPD  pg  4) 

PRC  153 
(ECO  pg  19) 

PRC  153 
(ECO  pg  19) 

PRC  153 
(ECO  pg  19) 

Headsets 

(included  with  radio) 

Headsets 

(included  with  radio) 

Heads  Up  Display^ 
Internal  Earpiece^ 

Handheld  GPS 
(ECO  pg  23) 

Laptop  (MR-1) 
(embedded  GPS) 
(ECO  pg  29) 

Touch  Pad^ 

GPS  Battery 

Laptop  Battery^ 

Touch  Pad  Battery^ 

Radio  Battery'^ 

Radio  Battery"^ 

Radio  Battery'^ 

Piezo-electric  Power 

*http://www.laptopbattervdepot.com/shopping/productdetails.asp 

sales@glaciercomputer.com 

^http://www.myshopping.com 

‘^http://www.buchmann.ca/article20-pagel.asp 

'"’http  ://customearpiece. com/category  .php?id=18&gclid=CN71y7aA5pwCFRkpawodp08gFQ 

The  costs  are  derived  from  both  parametric  cost  analysis  based  on  subject  matter 
expert  inputs  and  actual  costs  based  on  published  documentation  from  respective 
programs  while  other  costs  were  obtained  through  internet  research.  SMEs  provided  unit 
prices,  system  specifications  (including  size,  weight  and  power  data  used  in  other 
sections  of  this  paper),  and  capability  estimates  based  on  current  systems  of  record.  The 
SMEs  were  able  to  provide  a  rough  estimate  when  actual  cost  data  for  the  respective 
system  was  unavailable.  Unknown  variables  such  as  integration  costs  were  given  best 
effort  analyses  to  determine  reasonable  cost  ranges. 

The  costs  for  each  of  the  alternatives,  broken  down  by  components  and  compiled 
into  an  acquisition  cost,  are  displayed  in  Figure  29  through  Figure  32. 
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Figure  29:  Primitive  Alternative  Component  Costs 
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Figure  30:  Current  Alternative  Component  Costs 
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Advanced  Alternative  Component  Costs 
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Figure  31:  Advanced  Alternative  Component  Costs 


Future  Alternative  Component  Costs 
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Figure  32:  Future  Alternative  Component  Costs 
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The  acquisition  costs  totals  for  each  alternative,  as  compared  to  the  other 
alternatives,  are  shown  in  Figure  33. 

Acquisition  Cost  Comparison 
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Figure  33:  Acquisition  Cost  by  Alternative 
2.  Operations  and  Sustainment  Costs 

“O&S  has  historically  been  the  largest  portion  of  Life  Cycle  Cost.  A  complete 
estimate  of  O&S  costs  will  typically  include  the  costs  of  personnel,  consumables,  goods 
and  services,  and  sustaining  support  and  investments  associated  with  the  peacetime 
operation  of  a  weapon  system.  Operating  and  support  costs  normally  constitute  a  major 
portion  of  system  life-  cycle  costs  and,  therefore,  are  critical  to  the  evaluation  of 
acquisition  alternatives.”  (Defense  Technical  Information  Center,  1992).  The  Rifleman 
Radio  CPD  supports  this  data  and  states  that  the  AN/PRC- 154,  which  provides  a  major 
portion  of  functionality  for  the  Advanced  and  Future  Alternatives,  has  O&S  costs  that  are 
65%  of  the  Total  Life  Cycle  costs. 

The  O&S  costs  for  the  hardware  are  shown  in  Figure  34  and  are  based  upon  the 
three  to  five  year  hardware  replacement  standard  and  the  software  upgrade  standard  every 

12  to  18  months.  The  normal  radio  replacement  plan  is  a  7-10  year  cycle.  The  O&S 
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costs  were  estimated  for  a  ten  year  period.  All  of  these  facts  are  taken  into  consideration 
in  determining  the  O&S  costs  for  the  alternatives  that  include  the  AN/PRC- 154  as  a 
component.  The  O&S  costs  are  further  extrapolated  to  the  other  alternatives  based  on  the 
similarity  of  the  systems. 

O&S  Cost  Comparison 


Alternatives 

Figure  34:  Operational  and  Supportability  Costs 

The  Rifleman  Radio  CPD  presents  O&S  as  the  largest  cost  contributor  in  the  PRC 
154  Total  Life  Cycle  costs.  The  O&S  costs  for  the  hardware  are  based  upon  the 
maximum  of  the  three  to  five  year  replacement  standard  and  the  software  on  an  18  month 
replacement  standard.  The  normal  radio  replacement  plan  is  a  7-10  year  cycle.  The 
fielding  schedule  for  PRC  154  is  FYll-18.  Additional  replacement  or  upgrade  fielding  is 
planned  at  the  end  of  the  AN/PRC- 154  lifecycle. 

3.  Total  Life  Cycle  Costs 

The  Total  Life  Cycle  Costs,  as  defined  for  the  purposes  of  this  project,  are  the 
combination  of  the  Acquisition  and  O&S  costs  as  shown  in  Figure  35. 
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Total  Life  Cycle  Cost  Comparison 
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Figure  35:  Total  Life  Cycle  Costs 

The  Primitive,  Current  and  Advanced  alternatives  costs  all  fall  within  a  $2300 
range.  The  Future  alternative  cost  is  between  three  and  four  times  as  much  as  the  others. 


F  ALTERNATIVES  SCORING  RESULTS  AND  SUMMARY 


After  the  execution  of  the  SE  process,  the  modeling  and  simulation,  capturing 
system  data  and  evaluating  the  results  from  all  of  the  analysis  efforts  described  above,  the 
teams  final  effort  was  completing  the  Decision  Analysis  process.  The  team  was  prepared 
to  make  a  recommendation  for  a  specific  alternative  and  COA,  based  on  the  quantitative 
data  shown  in  Table  19.  It  is  clear  from  the  Capability  vs.  Cost  mappings  in  Figure  36 
that  the  best  “bang  for  the  buck”  is  the  Advanced  Alternative. 
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Table  19:  Alternative  Scoring  Summary 


Alternative 

Primitive 

Current 

Advanced 

Future 

Benefits 

Metric 

Weighting  factor 

Best 

Threshold  value 

Objective  value 

Raw 

Rank 

Weighted  Rank 

Raw 

Rank 

Weighted  Rank 

Raw 

Rank 

Weighted  Rank 

Raw 

Rank 

Weighted  Rank 

Weight 

pounds 

20 

less 

10lbs 

5lbs 

■a 

6.7 

13.8 

4 

12.6 

2 

10.0 

5.7 

1 

20.0 

Battery  life 

hours 

15 

longer 

6hr 

8hr 

1 

3.0 

4.5 

3 

5.0 

6 

2 

8 

1 

15.0 

Ease  of  use 

1  though  7 
scale 

15 

4 

7 

4 

3.8 

5 

3 

5.0 

6 

H 

7 

15.0 

Reliability  -  MTBF 

% 

15 

more 

90 

99 

96.19 

3 

5.0 

96.39 

2 

96.26 

2 

99.48 

1 

15.0 

Workload 

workload 

units 

15 

less 

20 

m 

3.8 

14.5 

3 

5.0 

8.5 

H 

1 

15.0 

Incoming  message 
process 

% 

10 

more 

1# 

2# 

45 

1 

10.0 

45 

1 

10.0 

45 

1 

10.0 

45 

1 

10.0 

Outgoing  message 
process 

% 

10 

more 

1# 

2# 

19 

2 

5.0 

30 

1 

10.0 

30 

1 

10.0 

30 

1 

10.0 

Total  Score 

100 

37.2 

47.5 

60.0 

100.0 

Cost  ($)K 

$2.7 

$2.9 

$2.7 

$105.7 

Bang  per  Buck 

13.8 

16.4 

22.2 

0.9 
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Figure  36:  Capability  vs.  Cost  (“Bang  for  the  Buck”) 
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V  CONCLUSIONS  AND  RECOMMENDATIONS 


The  Team  Marine  System  Engineering  team  effectively  applied  the  practices, 
processes,  and  analysis  of  the  System  Engineering  Design  Process  (SEDP)  in  order  to 
understand  the  needs  of  the  customer.  The  team  considered  non  material  or  DOTLPF 
alternatives.  Non-material  alternatives  were  not  considered  to  be  viable  to  solve  the 
capability  problem.  Four  (4)  possible  material  alternative  solutions  were  developed  to 
meet  the  customer  requirements.  These  four  alternative  solutions  were  derived  from  the 
Functional  Architecture,  Physical  Architecture,  and  Operational  Architecture. 

Through  feasibility  screening,  modeling  and  simulation,  decision  scoring,  risk 
analysis  and  cost  analysis  the  team  determined  that  an  evolutionary  development  effort 
would  be  the  best  course  of  action  for  MCSC  to  undertake.  In  the  near-term,  the  team 
recommends  pursing  the  Advanced  Alternative.  This  alternative  is  the  best,  “bang  for  the 
buck”  integrated  solution.  As  systems  mature  and  technologies  become  available  the 
team  anticipates  that  MCSC  will  be  able  to  evolve  into  the  Future  Alternative.  Currently, 
the  future  alternative  is  not  ready  for  production  and  is  in  the  Concept  Development 
Phase  (DoD  acquisition  cycle). 

The  team  recommends  that  PM  MERS  continue  the  acquisition  and  development 
of  the  Advanced  Alternative,  migration  to  the  Future  Alternative,  and  consider  the 
following: 

■  Conduct  a  Life  Cycle  cost  estimate  for  the  Advance  approach  to  determine 
logistics  support; 

■  Conduct  a  Human  Factors  study  for  current  fielded  Squad  Leader 
communications  in  order  to  identify  shortfalls  in  capability  and  to  address 
these  shortfalls  in  the  next  generation  communication  system; 

■  Include  the  results  of  this  team’s  effort  as  the  foundation  for  future 
analysis  and  development. 
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APPENDIX  A 


A  PROJECT  TEAM  AND  STRUCTURE 
1.  Team  Structure 

Team  Marine  consisted  of  10  members,  as  seen  in  Figure  37  below, each  with 
various  educational  backgrounds  and  systems  engineering  experiences.  The  team 
nominated  Mr.  Larry  Bochenek  and  Mr.  Jeff  Dixon  as  the  Project  Lead  and  Co-Lead 
respectively. 


Lawrence 
Bochenek, 
Project  Lead 


JefferyDkon, 
Project  Co-Lead 


I  ■!  I  I 


ICrunal  Richard  Kathryn  H  Yancy  peter  Jonathan  Brenda  ■  Brian 

Amin  Elgart  Hunt  Jeleniewski  Manternach  Roach  Song 


Figure  37:  Team  Marine  Members 

Each  member  was  assigned  tasking  or  volunteered  to  work  on  specific  elements 
of  the  project.  Some  efforts  were  executed  as  individuals  and  many  others  were  executed 
as  teams,  as  seen  below  in  Figure  38:  Team  Marine  Functional  Area  Teams. 
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Figure  38:  Team  Marine  Functional  Area  Teams 

Figure  38  shows  how  the  team  divided  the  efforts  into  functional  areas  and 
worked  as  an  Integrated  Product  Team  (IPX). 

IPT  meetings  and  collaboration  sessions  were  established  to  meet  program 
objectives  within  each  program  phase.  As  an  IPX  completed  the  assigned  tasking  the  IPX 
lead  reported  to  the  Project  lead  the  status,  and  members  were  then  reassigned  as 
necessary. 
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APPENDIX  B 


B  PROJECT  RISK  MANAGEMENT 

1.  Risk  Management  Analysis 

The  goal  of  the  Team  Marine  Risk  Management  Program  is  to  implement 
methods  and  alternatives  that  keep  overall  program  risk  low.  To  accomplish  this  goal, 
Team  Marine  uses  a  centrally  managed  and  executed  risk  strategy.  The  risk  strategy  is  to 
identify  potential  risk  items  and  events  as  early  as  possible,  develop  mitigation 
alternatives  or  handling  options  and  reduce  the  potential  impacts  before  the  items  cause 
serious  cost,  schedule  and/or  performance  problems.  The  entire  team  participates  in  the 
Risk  Management  Board.  This  method  is  a  proactive  process  to  detect  and  mitigate  risk 
elements.  There  are  many  elements  of  risk  such  as  Programmatic,  Cost,  Schedule, 
Quality,  Time,  Human  Resources,  Communication,  Performance  as  well  as 
Organizational.  (Wideman,  1992).  For  the  purposes  of  this  report,  only  performance  risks 
will  be  evaluated. 

By  definition,  risk  is  defined  as  an  event  whose  occurrence  could  jeopardize  the 
successful  completion  of  the  project.  Risk  is  the  measure  of  the  potential  future  inability 
to  achieve  project  objectives  within  defined  cost,  schedule  and  performance  constraints 
Project  risks  are  thus  identified  and  accessed  for  the  probability  of  occurrence  and  its 
impact  on  successful  completion  of  the  project. 

2.  Risk  Management  Process 

Risk  management  process  will  utilize  two  key  factors  to  manage  risk.  The  two 
key  factors  are  probability/likeliness  of  occurrence  and  consequence  of  occurrence.  The 
probability  of  occurrence  is  defined  in  terms  of  percentage  values  with  respect  to 
schedule  and  performance.  The  levels  of  likelihood  of  an  occurrence  are  directly  related 
to  the  probability  of  occurrence  and  are  further  defined  in  Table  20. 

Table  20:  Likelihood  of  Occurrence  levels 


Probability/Likelihood  of  Occurrence  -  Performance 

Level 

Probability  of  Occurrence 

Definition 

1 

0.0<P<0.3 

Low  likelihood 
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2 

0.3<P<0.5 

Low  to  medium  likelihood 

3 

0.5<P<0.7 

Medium  likelihood 

4 

0.7<P<0.9 

Medium  to  high  likelihood 

5 

0.9<P<  1.0 

High  likelihood 

The  consequence  of  occurrence  is  the  impact  on  successful  completion  of  the 
project.  The  consequence  of  occurrence  is  defined  in  terms  of  percentage  values  with 
respect  to  schedule  and  performance.  The  specific  ‘Consequence  of  Occurrence’  levels 
are  directly  related  to  percentile  impacts  and  are  further  defined  in  Table  21. 


Table  21:  Consequence  of  Occurrence  levels 


Consequence  of  Occurrence  -  Performance 

Level 

Consequence  of  Failure 

Definition 

1 

0%  <  C  <  10% 

Minimal  impact 

2 

10%  <  C  <  20% 

Minimum  to  medium  impact 

3 

20%  <  C  <  30% 

Medium  impact 

4 

30%  <  C  <  40% 

Medium  to  Major  impact 

5 

C  >  40% 

Major  impact 

Based  on  probability  and  consequence  distribution  as  stated  above,  team  marine 
will  use  the  following  four  step  risk  management  approach. 

a.  Step  1:  Risk  Identification 

The  purpose  of  risk  identification  is  to  identify  risk  and  evaluate  its  relative 
severity.  The  evaluation  of  risk  identification  is  based  on  scale  ranging  from  1  to  5.  A 
rating  of  1  is  implies  lowest  severity  and  a  rating  a  5  implies  highest  severity.  The  end 
result  of  risk  identification  is  risk  mapping  matrix  value  of  probability  of  particular 
failure  with  respect  to  consequence  of  that  particular  failure.  The  risk  value  will  be 
identified  in  the  form  of  a  risk  cube  in  risk  tracking  and  control  phase  (step  4),  where 
several  project  risks  could  be  identified. 

b.  Step  2:  Risk  Assessment 

Risk  is  assessed  based  on  likelihood  of  occurrence  and  severity  of  the 
consequences  to  the  overall  project.  The  risk  assessment  is  a  calculated  Expected 
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Consequence  value.  Risk  is  calculated  as  a  product  of  probability  of  failure  and 
consequence  of  failure. 

Expected  Consequence  (EC)  =  Probability  of  failure  (Pf)  *  Consequence  of  failure  (Cf) 

c.  Step  3:  Risk  Mitigation 

Once  the  risk  has  been  accessed,  the  following  options  can  be  exercised  to  handle 
the  specific  project  risks: 

■  Accept  the  risk  and  do  nothing  more 

■  Mitigate  the  risk  by  expending  team  resources  to  reduce  likelihood  and/or 
severity 

■  Transfer  the  risk  by  an  agreement  with  another  party  to  eliminate  likelihood 
and/or  severity 

■  Deal  with  the  risk  as  it  occurs 


d.  Step  4:  Risk  Tracking  and  Control 

Risk  tracking  will  be  accomplished  by  a  risk  mapping  matrix  to  simplify  and 
illuminate  the  risk  management  process  and  status.  The  graphical  representation  of  risk 
mapping  matrix  is  shown  below  in  Figure  39. 


Consequence  of  Failure 
Figure  39:  Generic  Risk  Mapping  Matrix 


All  risk  items  pertaining  to  the  project  are  identified,  with  higher  risk  items 
prioritized  over  lower  risk  items. 

3.  Program  Risks 

fl.  Risk  #1:  Not  improving  communications  capability 
Risk  Identification:  The  team  has  identified  recommending  an  unimproved 
communications  capability  as  a  risk.  The  risk  is  identified  as  a  result  of  the  identification 
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of  the  primitive  alternative.  If  through  our  analysis  we  determine  that  the  primitive 
alternative  is  our  recommendation,  we  will  have  failed  to  provide  the  stakeholders  with 
their  requested  capabilities. 

Risk  Assessment:  The  risk  assessment  for  not  recommending  an  improved 
communications  capability  was  identified  as  a  minor  risk  with  a  rating  of  level  3.  The 
levels  of  probability  and  consequence  with  respect  to  performance  are  calculated  below: 
Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  0.3  =  Level  2 
Consequence  of  occurrence  with  respect  to  performance  =  C  =  40%  =  Level  5 

Therefore,  using  Expected  Consequence  criteria,  we  calculated  the  following 
EC  with  respect  to  performance  =  0.3'^0.40  =  0.33  =  12%)  =  Level  2 

According  to  the  EC  criteria,  the  consequence  impact  is  of  a  minimum  to  medium 
level  in  terms  of  performance. 

Risk  Mitigation:  The  consequence  of  risk  with  respect  to  performance  being  low, 
the  team  unanimously  agreed  to  accept  the  risk  and  do  nothing  more,  because  the  SE 
process  employed  was  expected  to  prevent  the  occurrence  of  recommending  an 
unimproved  communications  capability. 

Risk  Tracking  and  Control:  Figure  40  represents  the  tracking  and  control  of  Risk 

#1. 
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Figure  40:  Risk  #1  Mapping 
b.  Risk  #2:  Increasing  weight  beyond  acceptable  range 
Risk  Identification:  Each  of  the  alternatives  beyond  the  primitive  requires  an 
increase  or  modification  in  components  which  could  result  in  an  increase  in  weight 
beyond  the  acceptable  range.  One  of  the  goals  of  this  project  is  to  minimize  the  weight  of 
the  system.  The  severity  of  the  risk  is  rated  at  4  on  a  scale  of  5. 

Risk  Assessment:  The  probability  and  consequence  of  increasing  the  system 
weight  beyond  the  acceptable  range  was  identified  as  an  elevated  risk  with  a  rating  level 
of  4.  The  levels  of  probability  and  consequence  with  respect  to  performance  are 
calculated  below: 

Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  .8  =  Level  4 
Consequence  of  occurrence  with  respect  to  performance  =  C  =  70%  =  Level  5 
Therefore  using  Expected  Consequence  criteria,  we  get  the  following 
EC  with  respect  to  performance  =  0.8  0.7  =  0.56  =  56%  =  Level  5 

According  to  the  EC  criteria,  the  consequence  is  at  the  maximum  level  in  terms  of 
performance. 

Risk  Mitigation:  Since  the  consequence  of  the  risk  with  respect  to  performance  is 
at  the  highest  level,  the  team  unanimously  agreed  to  mitigate  the  risk  by  first  determining 
the  acceptable  weight  range.  Secondly,  the  team  assigned  the  greatest  weighting  factor  to 
system  weight.  As  a  result  of  the  mitigation  plan,  the  revised  values  for 
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probability/likelihood  of  occurrence  and  consequence  of  occurrence  with  respect  to 
performance  were  re-calculated  below: 

Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  0.2  =  Level  1 
Consequence  of  occurrence  with  respect  to  performance  =  C  =  5%  =  Level  5 
Therefore  using  Expected  Consequence  criteria,  we  get  the  following 
EC  with  respect  to  performance  =  0.2  ^0.05  =  0.01  =  1%  =  Level  1 

The  mitigation  provided  the  team  with  a  revised  EC  value  for  performance  which 
was  reduced  from  56%  to  1%. 

Risk  Tracking  and  Control:  Figure  41  is  the  mapping  matrix  for  Risk  #2  and 
represents  the  tracking  and  control  of  risk  before  and  after  the  mitigation. 
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Figure  41:  Risk  #2  Mapping 

As  shown  in  Figure  41,  Risk  #2  was  mitigated  to  a  much  more  controllable  and 
acceptable  level. 

c.  Risk  #3:  Recommending  a  solution  that  is  too  complicated 

Risk  Identification:  Certain  of  the  alternatives  contain  highly  technical 
components  such  as  the  heads  up  display,  piezoelectric  power,  and  touch  pad  computers. 
These  components  may  require  much  more  training  and  higher  order  thinking  than  that 
required  by  the  current  system.  The  severity  of  the  risk  is  rated  at  4  on  a  scale  of  5. 

Risk  Assessment:  The  probability  and  consequence  of  Risk  #3,  (recommending  a 
solution  that  is  too  complicated),  has  a  definite  impact  on  the  project.  The  levels  of 
probability  and  consequence  with  respect  to  performance  are  calculated  below: 
Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  0.8  =  Level  4 
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Consequence  of  occurrence  with  respect  to  performance  =  C  =  40%  =  Level  4 
Therefore  using  Expected  Consequence  criteria,  we  get  the  following 
EC  with  respect  to  performance  =  0.8  W.4=  0.36  =  36%  =  Level  4 

According  to  EC  criteria,  the  consequence  is  at  a  medium  to  major  level  in  terms 
of  performance. 

Risk  Mitigation:  Since  the  consequence  of  risk  with  respect  to  performance  is  at  a 
medium  to  major  level,  the  team  unanimously  agreed  to  mitigate  the  risk  by  evaluating 
the  ease  of  use  of  the  systems.  As  a  result  of  the  mitigation  plan,  the  team  was  able  to 
manage  and  revise  the  risk  assessment.  Both  the  probability/likelihood  of  occurrence  and 
consequence  of  occurrence  were  recalculated  based  on  the  mitigation  with  the  revised 
values  below: 

Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  0.3  =  Level  2 
Consequence  of  occurrence  with  respect  to  performance  =  C  =  40%  =  Level  4 
Therefore  using  Expected  Consequence  criteria,  we  get  the  following: 

EC  with  respect  to  performance  =  0.3  *  0.4  =  0.12  =  12%o  =  Level  2 

Therefore  the  revised  EC  values  for  performance  are  reduced  from  36%  to  12% 
and  thus  lowering  the  consequence  from  major  to  medium  to  medium  to  minimal  level. 

Risk  Tracking  and  Control:  Figure  42  represents  the  tracking  and  control  of  Risk 
#3  before  and  after  the  mitigation.  This  represents  a  risk  that  is  more  acceptable  to  adopt. 


Consequence  of  Failure 
Figure  42:  Risk  #3  Mapping 
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d.  Risk  #4:  Technology  Maturation 

Risk  Identification:  The  technology  maturation  for  some  components  included  in 
the  Future  Alternative  is  below  standard.  A  capability  that  is  non-existent  is  rated  at  a 
scale  of  4  out  of  5,  both  in  terms  of  probability  and  consequence. 

Risk  Assessment:  The  probability  and  consequence  of  non-existent  solutions  and 
architectures  could  have  major  impacts  in  addressing  objectives  and  effective  needs  of 
the  system.  The  levels  of  probability  and  consequence  with  respect  to  performance  are 
calculated  below: 

Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  1.0  =  Level  4 
Consequence  of  occurrence  with  respect  to  performance  =  C  =  90  %  =  Level  5 
Therefore  using  Expected  Consequence  criteria,  results  in  the  following. 

EC  with  respect  to  performance  =  1.0  "^0.9  =  0.9  =  90  %  =  Level  5 

According  to  EC  criteria,  the  consequence  impact  is  of  medium  to  major  level  in 
terms  of  performance. 

Risk  Mitigation:  Since  the  consequence  of  this  risk  is  high  with  respect  to 
performance,  the  team  unanimously  agreed  to  mitigate  risk  by  attaching  a  large  cost  to 
the  undeveloped  technology. 

As  a  result  of  the  mitigation  to  technology  maturation  the  following  risk 
parameter  was  revised  for  probability/likelihood  of  occurrence. 

Probability/Likelihood  of  occurrence  with  respect  to  performance  =  P  =  0.3  =  Level  1 
Therefore  using  Expected  Consequence  criteria,  we  get  the  following 
EC  with  respect  to  performance  =  0.3  "^1.0  =  0.30  =  30%  =  Level  4 

Therefore  the  revised  EC  values  for  performance  are  reduced  from  90%  to  30% 
and  thus  lowering  the  consequence  from  the  High  level  to  the  Medium  to  Major  level. 

Risk  Tracking  and  Control:  The  following  risk  mapping  matrix  represents  the 
tracking  and  control  of  risk  before  and  after  the  mitigation. 


-  112- 


5 


R4 

(before) 


1  2  3  4  5 

Consequence  of  Failure 

Figure  43:  Risk  #4  Mapping 
4.  Project  Risk  Status 

Table  22  summarizes  the  overall  project  risks  post  risk  mitigation  efforts. 


Table  22:  Project  Risk  Summary 


RISK  ID 

Likelihood 

Consequence 
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Level  2 

Level  2 

R2 

Level  1 

Level  5 

R3 

Level  2 

Level  2 

R4 

Level  1 

Level  4 

R4 

(after) 


Figure  44  below,  provides  an  overall  graphical  representation  of  all  identified 
project  risks  in  a  single  risk  mapping  matrix. 
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Figure  44:  Mapped  Project  Risks 
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APPENDIX  C 


C  MARINE  EXPEDITIONARY  RIFLE  SQUAD  (MERS)  ARCHITECTURE  VIEWS 

Table  23;  Operational  Information  Exehange  Matrix  (OV-3) 
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Table  24:  Operational  Information  Exchange  Matrix  (OV-3)  (cont.) 
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Figure  45:  MERS  OV-5  Context  Diagram 
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Figure  46:  MERS  OV-5  Operational  Activity  Model 
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Figure  47:  MERS  OV-5  Operational  Activity  Model  A1 
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Figure  48:  MERS  OV-5  Operational  Activity  Model  A2 
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Figure  49:  MERS  OV-5  Operational  Activity  Model  A3 
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Figure  50:  MERS  OV-5  Operational  Activity  Model  A3 
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APPENDIX  D 


D  RIFLE  SQUAD  COMMUNICATIONS  SYSTEM  STAKEHOLDER 

QUESTIONNAIRE 

Team  Marine  categorized  Stakeholders  in  three  categories: 

•  Sponsors/Decision  makers 

•  Clients/end  users 

•  Analysts/Evaluators 

Questions  for  Sponsors/Decision  makers  included: 

•  Can  a  new  system  be  developed  and  integrated  into  the  Marine  Squad? 

•  Can  an  "off  the  shelf  system  be  used? 

•  What  is  the  schedule? 

•  What  is  the  cost? 

•  Is  there  funding? 

•  Can  an  existing  program  be  used? 

•  When  is  the  system  needed? 

•  What  Tactics,  Techniques,  Procedures  need  to  be  added  or  revised? 

Questions  for  the  Clients/end  users 

•  What  are  your  requirements? 

•  What  are  your  training  requirements? 

•  Will  the  system  interface  with  other  systems? 

•  What  are  the  systems,  interfaces,  and  information  requirements? 

•  What  information  is  needed?  And  who  needs  it  and  when? 

•  What  are  the  skill  levels  of  the  members  in  the  squad? 

•  What  types  of  systems  are  employed  today?  What  are  the  "goods"  and  the  bads? 

•  What  capabilities  will  be  fielded  soon  within  the  next  12-24  months? 

Questions  for  the  Analysts/Evaluators: 

•  What  kind  of  testing  is  required? 

•  What  measures  will  be  used? 

•  Are  there  Human  system  interface  issues? 
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APPENDIX  E 


E  COMMUNICATIONS  SYSTEM  ARCHITECTURE 
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Figure  51:  Squad  Communication  System  Operational  View  AO 
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Figure  52:  Squad  Communication  System  Operational  View  A1 
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Figure  53:  Squad  Communication  System  Operational  View  A2 
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Figure  54:  Squad  Communication  System  Operational  View  All 
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Figure  55:  Squad  Communication  System  Operational  View  A23 
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Figure  56:  Squad  Communication  System  Operational  View  A24 
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Figure  57:  Squad  Communication  System  Functional  View  A-1 
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Figure  58:  Squad  Communication  System  Functional  View  AO 
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Figure  59:  Squad  Communication  System  Functional  View  A1 
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Figure  61:  Squad  Communication  System  Functional  View  A3 
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Figure  62:  Squad  Communication  System  Functional  View  A4 
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Figure  64:  Squad  Communication  System  Functional  View  A6 
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-  141  - 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


APPENDIX  F 


F  ACKNOWELDGEMENTS 

Mr.  John  Gay  (MCSC,  DC  SIAT) 

Mr.  J.  D.  Wilson  (MCSC,  DC  SIAT) 

Ms.  Jessica  DiFillipo  (MCSC,  Gruntworks) 

Major  Wallis  (MCSC,  PM  MERS) 

Mr.  Harold  Phillips  (Harris  Inc.) 

Mr.  Carl  DeSantos  (MCSC,  Gruntworks) 

Prof  Mark  Rhoades  (NPS) 

Prof  Eugene  Paulo  (NPS) 

Ms.  Ashley  Welsh  (MCSC,  Training  &  Education) 

Ms.  Pam  Null  (MCSC,  Training  &  Education) 

Lt.  Colonel  J.  “Jack”  Maddis  (MCSC,  The  one  who  started  this  whole  thing!) 
Mr.  Mark  Richter  (MCSC,  PM  MERS) 

Mr.  Zachary  Lobin  (MCSC,  PM  COMMS) 

Our  Families  (Thank  you  for  your  patience!) 


-  143  - 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


-  144- 


APPENDIX  G 


G  ACRONYM  LIST 


ACE 

BFT 

C2 

C4 

CDD 

COA 

COC 

CPU 

CTP 

CUI 

DC-SIAT 

DODAF 

DOTMLPF 

ECO 

FOC 

FRAGORDS 

GCE 

GPS 

GSE 

HQMC 

ICD 

IDEF 

IISR 

IOC 

IT 

JFCOM 

JITC 

JPO 

JROCM 

JTRS 

LCE 

MAGTF 

MCCDC 

MCOTEA 

MCSC 

MCWL 

MEF 

MERS 

MOE 


Aviation  Command  Element 
Blue  Force  Tracker 
Command  and  Control 

Command,  Control,  Communications  and  Computers 

Capabilities  Development  Document 

Course  of  Action 

Combat  Operations  Center 

Computer  Processing  Unit 

Common  Tactical  Picture 

Controlled  Unclassified  Information 

Deputy  Commander,  Systems  Engineering, 

Interoperability,  Architectures  and  Technology 

Department  of  Defense  Architectural  Framework 

Doctrine  Organization  Training  Materiel  Leadership 

Personnel  and  Facilities 

Enhanced  Company  Operations 

Full  Operational  Capability 

Fragmentation  Orders 

Ground  Command  Element 

Global  Positioning  System 

Ground  Soldier  Ensemble 

Fleadquarters  Marine  Corps 

Initial  Capability  Document 

Integration  Definition  for  Function  Modeling 

Interim  Intra-Squad  Radio 

Initial  Operational  Capability 

Information  Technology 

Joint  Forces  Command 

Joint  Integrated  Test  Center 

Joint  Program  Office 

Joint  Requirements  Oversight  Counsel  Memorandum 

Joint  Tactical  Radio  System 

Logistics  Command  Element 

Marine  Air-Ground  Task  Force 

Marine  Corps  Combat  Development  Command 

Marine  Corps  Operational  Test  &  Evaluation  Activity 

Marine  Corps  Systems  Command 

Marine  Corps  War-fighting  Laboratory 

MAGTF  Expeditionary  Force 

Marine  Corps  Expeditionary  Rifle  Squad 

Measures  of  Effectiveness 
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MSSE 

Master  of  Science  in  Systems  Engineering 

MTBF 

Mean  Time  Between  Failure 

NFS 

Naval  Postgraduate  School 

NSA 

National  Security  Agency 

OPORDS 

Operational  Orders 

OV 

Operational  View 

PDA 

Personal  Digital  Assistants 

PLl 

Position,  Location  Information 

PM-MERS 

Program  Manager  for  Marine  Expeditionary  Rifle  Squad 

POM 

Program  Objective  Memorandum 

POR 

Program  of  Record 

RR 

Rifleman  Radio 

SA 

Situational  Awareness 

SATCOM 

Satellite  Communication 

SE 

Systems  Engineering 

SEDP 

Systems  Engineering  Design  Process 

SME 

Subject  Matter  Expert 

TIP 

Tactics,  Techniques  and  Procedures 

USB 

Universal  Serial  Bus 

USMC 

United  States  Marine  Corps 

WARNORDS 

Warning  Orders 
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